Segmentation fault with mpz_inp_raw on gcc45
Marco Bodrato
bodrato at mail.dm.unipi.it
Fri Sep 17 16:51:42 UTC 2021
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
More information about the gmp-bugs
mailing list