Segmentation fault with mpz_inp_raw on gcc45

[Torbjörn Granlund]

  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