Re: unexpected MPZ_OVERFLOW

[Marco Bodrato]

Ciao,

Il giorno Sabato, Agosto 08, 2026 07:14 CEST, sisyphus <sisyphus359 at proton.me> ha scritto:
In Windows 11, I'm building gmp-6.3.0, using mingw-w64 ports of gcc-16.1.0 in the MSys2 shell.
I do both a 32-bit and 64-bit static builds.

With the 32-bit build, I can feed the above demo a value of 0xffffffbb, and the program runs to completion:

=============
32-bit build:
=============
D:\C>gcc -o huge32.exe gmp_huge.c -lgmp

D:\C>huge32 0xffffffbb
size of long: 4
size of mp_size_t: 4
GMP_NUMB_BITS: 32
size of int: 4
e: ffffffbb 4294967227
z set to 17
STILL ALIVE 1
STILL ALIVE 2
 
Oddly, with the 64-bit build, the maximum allowed value is lower - namely, 0xffffff7b.
Any more than that, and the 64-bit build hits the following MPFR_OVERFLOW in mpz/realloc.c, whereupon the program terminates silently:
 
D:\C>huge64 0xffffff7b
size of long: 4
size of mp_size_t: 4
GMP_NUMB_BITS: 64
size of int: 4
e: ffffff7b 4294967163
z set to 17
STILL ALIVE 1
STILL ALIVE 2
 
You are right, it is quite odd that both with 32-bit and with 64-bit the size of int (used for the size in limbs of the mpz_t type) and unsigned long (used for mp_bitcnt_t) are only 4 bytes.
To have all the functions correctly working, we need that two limits are not violated:
 - the number of “limbs” (32 or 64 bits) to store a number in an mpz_t variable must not overflow a (signed) int;
 - the number of bits that one can store in an mpz_t variable must not overflow the (unsigned) mp_bitcnt_t type, which is unsigned long.
 
On operative systems where the size of types are not changing for 32 and 64 bits, the limit basically are the same. 
But… with 32-bit limbs we have more granularity, so that we can stop allocating just 32 bits below the limit. With 64-bit limbs we have to stop 32 bits earlier, I mean 64 bits below the limit.
 
To change this, we should change the definition of the type mp_bitcnt_t. It can be done, but it would be an incompatible change.
Is this all working as intended ?
When the size of the type used for bit-count is the same for 32-bit or 64-bit; yes, it is working as intended.
 
Ĝis,m