Problems with mpz_set_str and huge strings

[Stefan Krah]

Torbjorn Granlund <tg at gmplib.org> wrote:
> Stefan Krah <stefan-usenet at bytereef.org> writes:
> 
>   Torbjorn Granlund <tg at gmplib.org> wrote:
>   > Stefan Krah <stefan-usenet at bytereef.org> writes:
>   > 
>   >   I'm having memory corruption problems when using mpz_set_str for some huge
>   >   strings. Valgrind tracks down the problem to an invalid write in __gmpn_sub_n.
>   >   
>   > GMP only supports numbers of 2^31-1 bits or less on a 32-bit computer.
>   > Your number is greater than that.
>   
> Actually, I am wrong.  2^32-1 is the intended limit.
> 
> I think your operands should be made to work, since they actually can be
> made to fit into memory.

It appears to be an overflow in mpz/set_str.c, where xsize is ultimately
negative (printf inserted by me):

Breakpoint 3, __gmpz_set_str (x=0xffe034ec, str=0xf7d6d2c2 "", base=10) at set_str.c:126
126     printf("str_size: %u  __mp_bases[]: %f  numb_bits+2: %d\n",
(gdb) n
str_size: 677741241  __mp_bases[]: 0.301030  numb_bits+2: 34
129       xsize = (((mp_size_t) (str_size / __mp_bases[base].chars_per_bit_exactly))
(gdb) p 677741241 / 0.301030
$1 = 2251407637.1125803
(gdb) p (long) (677741241 / 0.301030)
$2 = -2043559659
(gdb) n
131       MPZ_REALLOC (x, xsize);
(gdb) p xsize
$3 = -67108862


>   "There is no practical limit to the precision except the ones implied by the
>    available memory in the machine GMP runs on."
>   
>   This could be replaced by the actual limits. Then, in the manual the limits
>   could be added as a short subsection of "GMP Basics".
>   
> Well, I'd say that 2^32-1 bits is a limit imposed by the hardware on
> 32-bit computers.  Sure, on some sense one could have 2^32-1 *bytes*,
> but then only one operand, and nowhere to place the result of any
> arithmetic, and no space for the program.

Yes, of course, but I was thinking 2^31-1 bits.


Stefan Krah