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: Paul Eggert
Subject: Re: [PATCH] Change module interface to no longer use GMP objects directly.
Date: Wed, 20 Nov 2019 13:24:36 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

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

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.

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.



reply via email to

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