Paul Eggert <
address@hidden> 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.