From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sat, 21 Nov 2015 15:25:41 -0800 Organization: UCLA Computer Science Department Message-ID: <5650FD75.5030707@cs.ucla.edu> References: <876118u6f2.fsf@lifelogs.com> <8737w3qero.fsf@lifelogs.com> <831tbn9g9j.fsf@gnu.org> <878u5upw7o.fsf@lifelogs.com> <83ziya8xph.fsf@gnu.org> <83y4du80xo.fsf@gnu.org> <564E6081.9010805@cs.ucla.edu> <564E6352.20701@cs.ucla.edu> <564F86FF.6030202@cs.ucla.edu> <564FA768.40504@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1448148379 9175 80.91.229.3 (21 Nov 2015 23:26:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Nov 2015 23:26:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Philipp Stephani , Eli Zaretskii , Ted Zlatanov , =?UTF-8?Q?Aur=c3=a9lien_Aptel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 22 00:26:09 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a0HXg-00063r-R4 for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 00:26:04 +0100 Original-Received: from localhost ([::1]:54103 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0HXg-0006FK-Bi for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2015 18:26:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0HXQ-0006EF-87 for emacs-devel@gnu.org; Sat, 21 Nov 2015 18:25:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0HXP-0002dT-HT for emacs-devel@gnu.org; Sat, 21 Nov 2015 18:25:48 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:40865) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0HXL-0002dB-KY; Sat, 21 Nov 2015 18:25:43 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 54DD5160D25; Sat, 21 Nov 2015 15:25:42 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id X1kH0BzQue4h; Sat, 21 Nov 2015 15:25:41 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 997F5160DFE; Sat, 21 Nov 2015 15:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uqelD4AphvAY; Sat, 21 Nov 2015 15:25:41 -0800 (PST) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 70E64160D25; Sat, 21 Nov 2015 15:25:41 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194971 Archived-At: Philipp Stephani wrote: > I honestly can't think of a situation where version checking would work but > size checking wouldn't. For example, a structure contains an off_t value, and time_t grows from 32 to 64-bits. The designer knew this might be a problem because of Y2038 issues, and so created padding for the time_t to grow into. Another example: suppose we change ptrdiff_t back to int. Another example: suppose we want the same module to work in both narrow and wide int Emacs, so we allocate storage for wide integers even though half of them are not used in narrow platforms. What you're saying, if I understand it, is that we promise that we'll never make any changes like that. This sounds overly constraining, at least for now. While the interface is experimental we'll retain the freedom to make arbitrary changes to it. When it settles down we can think about promises about never ever making changes in the future. In the meantime the size field is experimental and maybe we'll think of uses for it other than sizes.