[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: [PATCH] Change module interface to no longer use GMP objects directly.
Date: Wed, 20 Nov 2019 17:12:52 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]