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: Sat, 21 Nov 2015 08:54:41 +0000 Message-ID: References: <87egfzuwca.fsf@lifelogs.com> <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: multipart/alternative; boundary=001a114b07d417dc900525092538 X-Trace: ger.gmane.org 1448096118 5557 80.91.229.3 (21 Nov 2015 08:55:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Nov 2015 08:55:18 +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 Sat Nov 21 09:55:17 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 1a03ww-0000XE-Jy for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2015 09:55:14 +0100 Original-Received: from localhost ([::1]:51526 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a03wr-0000uB-Lf for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2015 03:55:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47654) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a03wc-0000ts-OV for emacs-devel@gnu.org; Sat, 21 Nov 2015 03:54:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a03wb-0000or-E9 for emacs-devel@gnu.org; Sat, 21 Nov 2015 03:54:54 -0500 Original-Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:34774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a03wZ-0000oP-DL; Sat, 21 Nov 2015 03:54:51 -0500 Original-Received: by wmvv187 with SMTP id v187so100922783wmv.1; Sat, 21 Nov 2015 00:54:50 -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=niJEu+nrjf01zPr3QR5aP3FRhRGmyLeehb7JmCahgnU=; b=1Iftq7lOdUwj/hZ+yCQVQaWy9NtjJkxupxuceLxjpkNYve0HtZwYJd7kWPYnOS5MWM q+C93cWtk+mloDO4Z38x+vfB3+d6AMmlodd/MhrMG0aIBIkViu/NNnufHIT5DB8K7oDV /+xHvaNR6saiMRPx4R65wjNjCsQ9fYNfgOLEo/YeBItGdL8Ych7meOXX/q5F28nMCVtl 41QJ5qDXC1isfPRJPJteW0xZlMZsJ4ngSVctncqjEFIR+t4TpScdGsSkiJHx+8HfNQbB taS2kwfAygJSiuqziH9L5onV/7k5vbmgderf0KHYrQQaNrm7hDBBGuOfxAe7TYFZW9TV dcQQ== X-Received: by 10.28.187.4 with SMTP id l4mr4514152wmf.33.1448096090805; Sat, 21 Nov 2015 00:54:50 -0800 (PST) In-Reply-To: <564FA768.40504@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::229 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:194927 Archived-At: --001a114b07d417dc900525092538 Content-Type: text/plain; charset=UTF-8 Paul Eggert schrieb am Sa., 21. Nov. 2015 um 00:06 Uhr: > Philipp Stephani wrote: > > the Windows API uses this approach extensively > > for version checking, and has been forward- and backward-compatible for > > decades with it. > > This sort of approach might work in the MS-Windows world, which has a > single > dominant supplier. It's not clear that it would work in the GNU/Linux > world, > where different suppliers have different ABIs. And even if one takes > exactly > the same Emacs source and module source and runs on the same operating > system, > one can easily build Emacs executables that won't interoperate with > modules, > simply by using different compiler flags. Do you refer to different structure layouts due to padding differences? That would need to be ruled out somehow, maybe by making the padding explicit in emacs-module.h. I also don't see how version checks should be able to protect against this. If a module expects a structure member at a certain offset, it has to be placed at that offset. There is no way in C how to check for that at runtime. > The sizes might match, but the code > won't. So I don't think sizes will suffice, at least, not outside of > MS-Windows. > > I honestly can't think of a situation where version checking would work but size checking wouldn't. Given that users will use modules compiled with arbitrary versions of emacs-module.h together with arbitrary Emacsen, the following compatibility constraints have to be fulfilled: - Types of structure members may never change. - Structure members may never be reordered. - Structure members may never be removed. - New structure members can only be added at the end. Otherwise we'd need to export different versions of the structures and module authors would have to pick the correct version at runtime, which is more error-prone. Given these constraints, version number checks are equivalent to size checks. This isn't really related to Windows; these are ABI compatibility constraints that always occur when passing structures. > Daniel's message pointed to JNI for an inspiration. JNI uses version > numbers > here (its GetVersion method), not sizes, I assume partly for the reasons > discussed above. Shouldn't we do the same? Not necessarily. Daniel had good reasons to deviate from the JNI design in this respect: size checks are simpler and less error-prone because users don't need to remember or look up which member is present in which version. --001a114b07d417dc900525092538 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am Sa., 21. Nov. 2015 um 00:06=C2=A0Uhr:
Philipp Stephani wrote:
> the Windows API uses this approach extensively
> for version checking, and has been forward- and backward-compatible fo= r
> decades with it.

This sort of approach might work in the MS-Windows world, which has a singl= e
dominant supplier.=C2=A0 It's not clear that it would work in the GNU/L= inux world,
where different suppliers have different ABIs.=C2=A0 And even if one takes = exactly
the same Emacs source and module source and runs on the same operating syst= em,
one can easily build Emacs executables that won't interoperate with mod= ules,
simply by using different compiler flags.

D= o you refer to different structure layouts due to padding differences? That= would need to be ruled out somehow, maybe by making the padding explicit i= n emacs-module.h.
I also don't see how version checks should = be able to protect against this. If a module expects a structure member at = a certain offset, it has to be placed at that offset. There is no way in C = how to check for that at runtime.
=C2=A0
=C2=A0 The sizes might match, but the code
won't.=C2=A0 So I don't think sizes will suffice, at least, not out= side of MS-Windows.


I honestly can't think of a situat= ion where version checking would work but size checking wouldn't. Given= that users will use modules compiled with arbitrary versions of emacs-modu= le.h together with arbitrary Emacsen, the following compatibility constrain= ts have to be fulfilled:
  • Types of structure members may n= ever change.
  • Structure members may never be reordered.
  • Stru= cture members may never be removed.
  • New structure members can only = be added at the end.
Otherwise we'd need to export differ= ent versions of the structures and module authors would have to pick the co= rrect version at runtime, which is more error-prone. Given these constraint= s, version number checks are equivalent to size checks. This isn't real= ly related to Windows; these are ABI compatibility constraints that always = occur when passing structures.
=C2=A0
Daniel's message pointed to JNI for an inspiration. JNI uses version nu= mbers
here (its GetVersion method), not sizes, I assume partly for the reasons discussed above. Shouldn't we do the same?=C2=A0

<= /div>
Not necessarily. Daniel had good reasons to deviate from the JNI = design in this respect: size checks are simpler and less error-prone becaus= e users don't need to remember or look up which member is present in wh= ich version.=C2=A0
--001a114b07d417dc900525092538--