GMP and 64-bit systems

[NightStrike]

On 6/1/08, librik at panix.com <librik at panix.com> wrote:
> What's the issue with 64-bit C types?  Here's a quick background document
> for you, the "Aspen paper" describing the three models and why most Unix
> systems standardized on LP64.
>    http://www.unix.org/version2/whatsnew/lp64_wp.html
> A summary for the impatient:  there are three ways to extend C types to
> a world where pointers and size_t's are 64 bits wide.
> * LP64 defines "int" as 32 bits and "long" as 64 bits.
> * LLP64 defines "int" and "long" as 32 bits, and an additional type
>  (usually called "long long") as 64 bits.
> * ILP64 defines "int" and "long" as 64 bits.
> ALL THREE ARE EQUALLY VALID APPROACHES.

<snip>

> Since I spend a lot of my work time cleaning up people's less-than-
> portable 64-bit source code, please allow me a short moment of stupid,
> unfair, irrational ranting:
> ** If you use the "long" type as an integer guaranteed to hold a pointer
>   or a memory size, you are a BAD C PROGRAMMER.  I don't care if it's
>   what you're used to.  It's NOT CORRECT.  Please stop! **

I wanted to highlight these two things.  What you said is very
correct, and needs to be read by a lot of people on this list.

> But most of the time it is simply better to write it yourself.
> That gives the user or the autoconf system more control over the
> library's ABI.

This I think I disagree with.  I think it's best to pick something
that adheres to some standard (size_t, intptr_t, etc) and fall back on
something else, something less standard, via autoconf if it's
unavailable.  Perhaps that's what you meant, though.