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