From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 22 Nov 2015 09:15:23 +0000 Message-ID: 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> <5650FD75.5030707@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114b6af605044405251d8da3 X-Trace: ger.gmane.org 1448183745 7240 80.91.229.3 (22 Nov 2015 09:15:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 09:15:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert , 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 10:15:44 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 1a0QkI-0004jW-SO for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 10:15:43 +0100 Original-Received: from localhost ([::1]:55271 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0QkI-000176-OP for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 04:15:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40225) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0QkE-00016z-Jx for emacs-devel@gnu.org; Sun, 22 Nov 2015 04:15:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0QkD-0005Bs-2o for emacs-devel@gnu.org; Sun, 22 Nov 2015 04:15:38 -0500 Original-Received: from mail-wm0-x233.google.com ([2a00:1450:400c:c09::233]:38023) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0QkA-0005BW-Fs; Sun, 22 Nov 2015 04:15:34 -0500 Original-Received: by wmec201 with SMTP id c201so69914034wme.1; Sun, 22 Nov 2015 01:15:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=khRACnAjh7GBK9pVqjQymYfPWT3YFz1G0aS/EzWy7x4=; b=AgaexqSHDvdcCpTEX9R+nL3/WYq2VFFnj1i4PfFpj0zOBaMXvF7/oRc7lj9xPyddZL MxDN7fmreCsyDlWz5EpfzrKlbG15X810PRAf9AdkDtwtoVZAgVXuyMqZd5Tw6UGnx5o5 0gI7Ej/hHoC4QF5gNOwA20Byu763eoq8atYMlQwmgMRpQZEKCSqEW/KvBu7YmEBzWKMC UpLhS354eP654YAOqxpJLYx/gbdbHC78Traxbn7BVXHdn6nfPxrHikUHgKM9kGAgmI4o ewXlmedbJh0q+UYXAR7I2Ana5XSLKgCsJof46HJr2/oiukNR+b4epqSSNhX2xmueVAsL ORaQ== X-Received: by 10.28.72.137 with SMTP id v131mr10437909wma.63.1448183733747; Sun, 22 Nov 2015 01:15:33 -0800 (PST) In-Reply-To: <5650FD75.5030707@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::233 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:194993 Archived-At: --001a114b6af605044405251d8da3 Content-Type: text/plain; charset=UTF-8 Paul Eggert schrieb am So., 22. Nov. 2015 um 00:25 Uhr: > 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. > Such issues are why we generally prefer fixed-size integers. Currently the structures contain only pointers and pointer-sized integers. If we are careful to keep it that way, sizes can only ever increase. > > 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. > The module interface never exposes Lisp_Objects directly, so it's immune to such considerations. > > 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. > Not really, because there are no cases where we'd need to e.g. expose an off_t field. We only need three types of fields: - A field for version checking (size should be reasonably fixed) - A pointer-sized field pointing to private data (size is fixed within a single address space) - Function pointer fields for interacting with Emacs (size is fixed within the address space) If we ever need to expose an off_t value, it will be in the form of another function pointer. Even if, for whatever reason, we must expose an off_t value directly, we can insert appropriate padding to make sure the size increases. > 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. > The module interface is supposed to be stable at least for the lifetime of Emacs 25. At least from our side it's not meant to be experimental. --001a114b6af605044405251d8da3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am So., 22. Nov. 2015 um 00:25=C2=A0Uhr:
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.=C2=A0 The designer knew this might be a problem because of Y2038 i= ssues, and
so created padding for the time_t to grow into.

Another example: suppose we change ptrdiff_t back to int.
<= div>
Such issues are why we generally prefer fixed-size integ= ers.
Currently the structures contain only pointers and pointer-s= ized integers. If we are careful to keep it that way, sizes can only ever i= ncrease.
=C2=A0

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 the= m are
not used in narrow platforms.

The modul= e interface never exposes Lisp_Objects directly, so it's immune to such= considerations.
=C2=A0

What you're saying, if I understand it, is that we promise that we'= ll never make
any changes like that.=C2=A0 This sounds overly constraining, at least for = now.

Not really, because there are no c= ases where we'd need to e.g. expose an off_t field. We only need three = types of fields:
- A field for version checking (size should be r= easonably fixed)
- A pointer-sized field pointing to private data= (size is fixed within a single address space)
- Function pointer= fields for interacting with Emacs (size is fixed within the address space)=
If we ever need to expose an off_t value, it will be in the form= of another function pointer.
Even if, for whatever reason, we mu= st expose an off_t value directly, we can insert appropriate padding to mak= e sure the size increases.
=C2=A0
While the interface is experimental we'll retain the freedom to make ar= bitrary
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 experimenta= l and
maybe we'll think of uses for it other than sizes.

The module interface is supposed to be stable at least for = the lifetime of Emacs 25. At least from our side it's not meant to be e= xperimental.
--001a114b6af605044405251d8da3--