Problem with large values in GMP...

[Torbjörn Granlund]

tg at gmplib.org (Torbjörn Granlund) writes:

  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.
  
It might be worth noting that this might in fact not be a bug in
overflow detection.  Instead, it might be related to that the bit count
(presumably returned by mpz_sizeinbase) is somehow truncated to 32 bits.

My reasoning about LP64 and LLP64 does not cover the full complexity
that GMP needs to deal with.   We also have ILP32 systems which use
64-bit mp_limb_t (e.g., x32, mips n32, and a few more).  The only LLP64
system to my knowledge is Window-64.

For LLP64 systems, using long long types does not incur any cost;
registers and arithmetic are natively 64 bits.

That's true for ILP32 systems too; these are 64-bit CPUs running in
32-bit pointer mode.  But they do pose an extra problem in that our use
of size_t in some places will overflow.  I good example is
mpz_sizeinbase; it returns a size_t whereas it would need to return a
long long type.

Then we have gmp_*printf and gmp_*scanf; they use plain int for sizes
(return values, * arguments).  Changing this to long won't cut it on
either LLP64 or ILP32+longlong_limb systems.  We don't have any suitable
type abstraction , not does the C standard...

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