Re: bignum branch

[Andy Moreton]

On Tue 17 Jul 2018, Paul Eggert wrote:

> Eli Zaretskii wrote:
>> But that problem will affect all platforms, wouldn't it?  Because GMP
>> can only work with 'long', and I guess we don't want to rely on stuff
>> like 'prtdiff_t' and 'intmax_t' being no wider than 'long'?  We'd need
>> to convert the other types explicitly.
>
> Yes, of course. However, the more of these types are wider than a GMP limb,
> the more problems we'll have.

The size of a GMP limb is irrelevant - it is the API for getting native
integer types into mpz_t values that cannot handle interger types wider
than long.

Wider mp_limb_t types improve efficiency, but do nothing about
correctness on LLP64 systems.

> There's another thing about debugging. This stuff is still uncertain. That is,
> there are no doubt bugs in the bignum branch in this area, and we don't know
> yet how significant these correctness problems will be. With that in mind, it
> would be useful to have avoid-libgmp options with our own GMP replacement that
> uses uintmax_t limbs (or 'unsigned int' limbs, for that matter) for debugging
> purposes, to help us debug the inevitable glitches that will arise due to
> libgmp's limbs being wrong for some types.

Again, this is unrelated to the API problem.

    AndyM