Yes, but, should we really consider it only a temporary overflow? Does GMP support mpz numbers with a bit-lenght that overflows?
GMP does not support such sizes. My fix avoided the overflow, allowing GMP overflow detection in the (re)allocation functions. It makes sense from a bookkeeping overhead perspective to let the (re)allocation handle overflow; we get it for free without any calculation. Then, maybe something like the following could do? --- a/mpz/inp_raw.c Tue Sep 14 19:05:51 2021 +0200 +++ b/mpz/inp_raw.c Fri Sep 17 18:49:14 2021 +0200 @@ -87,9 +87,11 @@ csize = size - 0x80000000u - 0x80000000u; abs_csize = ABS (csize); + if (abs_csize > ~(mp_bitcnt_t) 0 / 8) + return 0; /* Bit size overflows */ /* round up to a multiple of limbs */ - abs_xsize = BITS_TO_LIMBS (abs_csize*8); + abs_xsize = BITS_TO_LIMBS ((mp_bitcnt_t) abs_csize * 8); if (abs_xsize != 0) { I suppose that, in this case, as my fix has problems with nails, this might be a better patch. An UNLIKELY(...) might have a place here, though. I took a very quick lock at other uses of BITS_TO_LIMBS and think we might have one more place where scalar overflow might occur: mpz/import.c. There might be more places. -- Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs