Roberto Bagnara bagnara@cs.unipr.it writes:
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'.
I'm afraid I don't follow your reasoning here.
(I don't think any mpz/mpq/mpf functions accept mp_size_t arguments. The _ui functions accept an (unsigned) long int but that's 32-bit or 64-bit numerical data, which will at most add 32 or 64 to the _mp_size argument.)
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.)
Yes, this is intended. It saves a lot of memory for smallish numbers on 64-bit systems, since the mpz_t will use 24 bytes instead of 32 bytes.
We use mp_size_t in the mpn layer to allow larger precisions there, and mp_size_t in scalars elsewhere since 64-bit scalar arithmetic is often somewhat faster on 64-bit machines. (Now there is an exception to this rule in the AMD64 clone Pentiums, where 64-bit arithmetic is often much slower than 32-bit arithmetic.)