GMP and 64-bit systems
nightstrike at gmail.com
Sun Jun 1 17:57:05 CEST 2008
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.
> 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.
> 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.
More information about the gmp-discuss