Re: bignum branch

[Eli Zaretskii]

> Cc: address@hidden
> From: Paul Eggert <address@hidden>
> Date: Sun, 15 Jul 2018 10:31:04 -0700
> 
> Eli Zaretskii wrote:
> > 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.
> 
> It'd still have to jump through the hoops for 32-bit systems --with-wide-int, 
> though.

Yes.  And maybe also for other platforms.

> Instead, how about fixing our GMP substitute source code to work for 
> this situation, and fall back on it when GMP proper doesn't handle long long? 

Not sure what you mean by "our GMP substitute source code".  Do you
mean mini-gmp?  I didn't yet look at it, and so I don't know what that
means in practice.  (Someone said it's less efficient than GMP?)

> That should work for both 32-bit --with-wide-int and MinGW64, and won't 
> require 
> us to wait for any action on the part of MSYS2 or the GMP maintainers.

There's no need to wait anyway.  We should condition use of GMP on
EMACS_INT being not wider than the appropriate GMP type (I guess
mp_bitcnt_t?), and then if and when GMP learns to support 64-bit
Windows, things will "just work".