Ciao, Il 2021-09-16 23:27 Torbjörn Granlund ha scritto:
Going from byte count to bit count to limb count is non-trivial without risking overflow, even if the end result will typically be smaller than the incoming byte count (assuming we're not using gmp/asl.h with tiny
Yes, but, should we really consider it only a temporary overflow? Does GMP support mpz numbers with a bit-lenght that overflows?
Perhaps, instead of the change below which triggers an errir in the allocation statement later in the program flow, we could make an explicit check of the byte count vs the max supported sizes, and generate the overflow error locally.
I agree! We do not define BITCNT_MAX anywhere, do we? 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) { Ĝis, m _______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs