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

[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.

>> opy_string_contents never returns false. If it signals an error, it
>> does not return. If it returns, it always returns true. It's pretty
>> weird, but there it is.
> 
> No, it returns false in case of an error. Module functions always return.

Ah, thanks, I see now; it's handled by MODULE_FUNCTION_BEGIN. OK, I'll 
withdraw this part of my comment; we can live with returning a bool.

> 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. :-)