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 - 0x8000u - 0x8000u;
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
