Problem with large values in GMP...

[Torbjörn Granlund]

wraithx at morpheus.net writes:

  So, would something similar happen during normal mpz_mul operations?
  Here is the behavior I was originally trying to understand:
  
  mpz_mul(num3, num1, num2)
  num bits in num1 = 4006516961
  num bits in num2 =  288450334
  num bits in num3 = 4294967295
  
  mpz_mul(num3, num1, num2)
  num bits in num1 = 4006516961
  num bits in num2 =  288450365
  num bits in num3 =         30
  
That's not supposed to happen.  We try to detect spill.

Please report this to gmp-bugs.

  I know there is probably a deep and/or complicated answer to this, but
  why not make mp_bitcnt_t (and mp_size_t, etc... ?) into the same type
  as mp_limb_t? What portability is lost by making this change?  Is it
  that you don't want to lose backwards compatibility with existing code
  bases?  Or that this change might cause subtle problems throughout the
  library that would have to all be fixed?  Or maybe something else?
  
Making mp_size_t follow the size of mp_limb_t should be safe, except
that it is not 100% source or binary compatible.

See <https://gmplib.org/devel/incompatibility.html>.

  I don't know if I could help much, but I'd be willing to test any
  changes or test versions.  Maybe I could try creating a local
  experimental copy of 6.1.0 with these changes and seeing if I can get
  it to work?  I know this is a big library, so I'm probably
  (definitely?!) biting off more than I can chew.  I know that LLP64
  systems are a kind of second class citizen, but I'd like to see it
  gain equal, or closer-to-equal, footing with LP64 systems.  Do you
  have any tips or hints of things that I should look for when making
  these changes?  Are there other types that I should expand?  Thanks
  again for making this great library and thanks for any help you can
  provide.
  
I believe it to be possible to make LP64 and LLP64 systems work mostly
equally well with GMP, but not within the current compatibility
promises.

We use our own type for sizes, mp_size_t, which unlike size_t is signed,
and also unlike size_t will not automatically follow the size of
pointers; it is never declared as anything greater than `long'.

So mp_bitcnt_t and mp_size_t would need to be defined as 'long long'
types, and then the result would need to be tested on a LLP64 system
with lots of RAM.

Our tests (in gmp/tests) do not allow for simple parameterisation for
making them generate huge numbers.  The exception is mpz/t-mul.c.  This
is a major problem with validating the function around 2^31 and 2^32 bit
operands.


-- 
Torbjörn
Please encrypt, key id 0xC8601622