Re: bignum branch

[Andy Moreton]

On Sun 15 Jul 2018, Eli Zaretskii wrote:

>> From: Andy Moreton <address@hidden>
>> Date: Sat, 14 Jul 2018 21:04:38 +0100
>> 
>> The problem is that if EMACS_INT is "long long", then the calls to
>> mpz_*_si() API routines will truncate any values passed to GMP. This
>> means that emacs cannot use any the mpz_*_si() routines directly.
>
> Right, I see what you mean now: all those APIs accept 'long' or
> 'unsigned long' as the integral type.  So this is a limitation of GMP
> as of now.  This message:
>
>   https://gmplib.org/list-archives/gmp-discuss/2016-March/005966.html
>
> indicates that GMP developers plan to address this in version 7, but
> the current master branch of GMP is still on version 6, so I guess it
> will be a while.

Indeed - I don't see this being addressed anytime soon.

> Btw, I had a cursory look at the GMP sources, and it seemed to me that
> changing GMP to lift this limitation should not be too hard.  The
> patch shown in this message:
>
>   https://gmplib.org/list-archives/gmp-discuss/2016-March/005965.html
>
> seems to confirm that.  So maybe someone could build GMP with MinGW64
> after applying that patch, and if it works, submit the patches to
> MSYS2 guys so that they could release a fixed library.  Then Emacs
> won't need to jump through these hoops on 64-bit Windows systems.

A quick look at that patch shows that it does not address all of the
issues. It fixes problems with large bitwidth numbers, but does not
handle other problems where the code assumes that long is not smaller
than mp_limb_t.

I think we will need to work around this in emacs until a better
upstream solution is available.

    AndyM