Problems with mpz_set_str and huge strings

Torbjorn Granlund tg at
Mon Jul 6 00:05:07 CEST 2009

Stefan Krah <stefan-usenet at> writes:

  Torbjorn Granlund <tg at> wrote:
  > Stefan Krah <stefan-usenet at> 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.

  Thanks for the explanation. Perhaps it's a good idea to publish the limits
  more prominently (if anyone has time to work on the documentation). For
  example, the main page currently says:
  "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.

For 64-bit computers it is a bit less true to claim the GMP has no
limits.  mpz/mpq/mpf limits operand sizes to 2^37 bits, while mpn might
work for much larger operands.  I write "might work" since I would be
quite surprised if there are no bugs where we try to use an int to store
a size somewhere.

(I hope to get a large memory computer within a year to make testing of
really huge operands possible.)


More information about the gmp-bugs mailing list