Hi there,
we have been bitten by a problem that can be explained as follows: on machines that are not Crays, `mp_size_t' is of type `long int':
#if defined (_CRAY) && ! defined (_CRAYMPP) /* plain `int' is much faster (48 bits) */ #define __GMP_MP_SIZE_T_INT 1 typedef int mp_size_t; typedef int mp_exp_t; #else #define __GMP_MP_SIZE_T_INT 0 typedef long int mp_size_t; typedef long int mp_exp_t; #endif
However, the `_mp_size' field of `_mpz_struct' is of type `int':
typedef struct { int _mp_alloc; /* Number of *limbs* allocated and pointed to by the _mp_d field. */ int _mp_size; /* abs(_mp_size) is the number of limbs the last field points to. If _mp_size is negative this is a negative number. */ mp_limb_t *_mp_d; /* Pointer to the limbs. */ } __mpz_struct; #endif /* __GNU_MP__ */
For some reason (assonance, quite likely), we were assuming that `_mp_size' was of type `mp_size_t' but this wrong assumption fails whenever `int' and `long int' are different types (which happens, e.g., on x86_64-unknown-linux-gnu).
Notice that I am not posting this to gmp-bugs because it is not, I believe, a bug of GMP: we are fiddling with the internal details of GMP and this is something that goes beyond the API. Nonetheless, I wonder why many GMP functions accepts parameters of type `long int' (on non-Crays) when they can never handle anything that does not fit `int'. Is this apparent discrepancy intended? (I know that a size of 2^31-1 fits all present and future purposes, but this does not explain why mp_size_t can go beyond that limit.) All the best,
Roberto