Re: bignum branch

[Andy Moreton]

On Sat 14 Jul 2018, Eli Zaretskii wrote:

>> From: Andy Moreton <address@hidden>
>> Date: Fri, 13 Jul 2018 20:35:18 +0100
>> 
>> The mpz_* API from libgmp uses "long" as the widest type for native
>> integers, which does not work on 64bit mingw64 on Windows, where "long" is
>> 32bit and "long long" (used for EMACS_INT) is 64bit.
>
> Isn't that a problem in how GMP was configured for MinGW64?  I see in
> the GMP sources that it does check for "long long", so why didn't that
> work during the build?
>
> In the file gmp-h.in (from which gmp.h is generated during the build),
> I see this:
[snipped]

The choice of word size for the limbs internal to GMP is irrelevant
here.

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.

Alternatives include:
a) Build 64bit emacs on Windows using 32bit long for EMACS_INT. This
seems undesirable as all values larger than 32bits are then bignums.

b) Use 64bit long long for EMACS_INT, and do extra work to pass native
values into GMP in two halves, i.e. something like:
    EMACS_INT i;
    mpz_t val, tmp;
    mpz_init_set_si(val, (i >> 32));
    mpz_mul_2exp(val, val, 32);
    mpz_init_set_si(tmp, (i & 0xffffffff);
    void mpz_ior(val, val, tmp);
    mpz_clear(tmp);

GMP does not yet support C99 types, so will result in awkward and
inefficient handling of 64bit vlaues on LLP64 systems.

    AndyM