Re: [PATCH] Change module interface to no longer use GMP objects directly.

[Philipp Stephani <p.stephani2@gmail.com>]

Am Do., 21. Nov. 2019 um 02:12 Uhr schrieb Paul Eggert <eggert@cs.ucla.edu>:
>
> On 11/20/19 1:30 PM, Philipp Stephani wrote:
>
> > I don't think we can do that either. emacs-module.h has to be
> > completely independent from the rest of Emacs. GMP allows changing the
> > limb at configure time and depending on some architecture flags, we
> > can't allow that.
>
> I don't see why not, as my proposal would continue to keep
> emacs-module.h independent of the rest of Emacs. emacs_limb_t would
> merely be a performance hint about GMP, and would not necessarily match
> the mp_limb_t that an Emacs module uses.
>
> Let's take an unusual and extreme example. Suppose Emacs is built with a
> a "normal" GMP that uses 64-bit limbs on the current platform, so its
> emacs-module.h defines emacs_limb_t to be a 64-bit integer. And suppose
> the module author builds with an "unsual" GMP that is configured to use
> 32-bit limbs on the current platform. Then emacs_limb_t might be
> 'unsigned long long int' while mp_limb_t is 'unsigned int' within module
> code. This combination will work: there will be two copies of the GMP
> library linked into the executable (the "normal" one and the "unusual"
> one), each with its own API and names and calling conventions; Emacs
> internals will call one copy and module code will call the other, and
> the module code will note that mp_limb_t and emacs_limb_t are different
> types and will fall back on the slower mpz_export method to copy integers.
>
> However, such an example will hardly ever happen. In practice, GMP is
> built one way for a particular platform, choosing a platform (which an
> Emacs builder needs to do anyway) will choose a particular GMP
> implementation, and Emacs's internal use of GMP will match the module's
> use so conversion will operate more efficiently.

That is not the issue I have in mind. The problem is that
emacs-module.h needs to be token-by-token identical for all platforms
- it's expected that distributors and users copy it around at will. We
can't have it depend on the platform that Emacs was built, or any
configure flags used for building Emacs.
Even if we allowed emacs-module.h to differ between platforms (which
we shouldn't), we still couldn't allow emacs-module.h to contain data
derived from configure flags, as then users specifying different
configure options could produce wrong/incompatible variants of the
header. It's crucial that there's a single canonical emacs-module.h.


> > The guarantee itself is fine with me (we should put an assertion into
> > the codebase to document it). I just wonder whether it's important
> > enough to actually make.
>
> Yes, I think so. (Admittedly I worry about integer overflow more than
> most people do. :-)

I definitely worry about it, too, and everyone should. I'm OK with
documenting the guarantee since it can prevent users from running into
undefined behavior.