Paul Eggert <eggert@cs.ucla.edu> 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.