emacs-devel
[Top][All Lists]
Advanced

[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: Philipp Stephani
Subject: Re: [PATCH] Change module interface to no longer use GMP objects directly.
Date: Wed, 20 Nov 2019 22:30:58 +0100

Am Mi., 20. Nov. 2019 um 22:24 Uhr schrieb Paul Eggert <address@hidden>:
>
> On 11/20/19 1:06 PM, Philipp Stephani wrote:
> > GMP seems to make a very complex series of choices when selecting the
> > limb datatype, which we can't and shouldn't replicate.
>
> We don't need to replicate GMP's reasoning. We can use a 'configure'
> time test to use whatever type GMP uses. The emacs-module header could
> be quite simple, and just use that type (typically unsigned long, but
> not always) when typedeffing emacs_limb_t. I'll write the configure-time
> code, so you don't need to worry about implementing it (not that it's
> hard to write).

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.

>
> > copy_string_contents
> > returns false if and only if it has signaled an error, which is a
> > quite useful invariant.
>
> No, copy_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.

>
> >> I found the guarantee useful in the first function I wrote that
> >> attempted to use the proposed API, so that's good evidence that it's
> >> worth documenting.
> >
> > I don't think so, it's a very narrow guarantee that we also don't give
> > for other functions.
>
> I don't think any of the other functions need such a guarantee (but if
> they do, we should provide it).
>
> > Each guarantee, however minor, comes with a cost:
> > we need to document it and stick to it forever.
>
> This particular guarantee has so little cost that the cost is not worth
> worrying about. It's a guarantee we'll never want to violate and there's
> essentially no cost to sticking to it "forever". I'll write the
> one-sentence documentation, if that helps.

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.



reply via email to

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