Why is _mp_size not of type mp_size_t?

[Torbjorn Granlund]

Roberto Bagnara <bagnara at 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.)
  
-- 
Torbjörn