Subject: Re: 64bit issues
To: None <isildur@guild.net, port-alpha@netbsd.org>
From: Ross Harvey <ross@ghs.com>
List: port-alpha
Date: 12/21/1999 17:23:28
Given that existing programs often play integer/pointer games, and given
that very few applications will be willing to require c9x conformance for
years to come, the question becomes: how to deal with such games without
rewriting the app and within a c89 or posix environment.
One example, I did a sweep of the xsrc/XFree86 sources a while back. One
game X plays is storing an integer in the [0] element of a pointer array.
That's easy to deal with, as pointers are always >= integer size. (This
wasn't always true, BTW, but can be considered so now.)
Fitting pointers into `int' is obviously hopeless, though. It might
help to compare the models you are likely to be faced with:
Model Meaning Used by
----- ------- ---- --
ILP32 int, long & pointer are 32 Almost every 32-bit environment
LP64 long & pointer are 64 Almost all 64-bit unix-like
LLP64 microsoft's grandiose rename of P64, an attempt to disguise
its bogosity
P64 a totally lame environment "thought" up by microsoft, where
only pointer and long long are 64 bits
So, `long' works, except according to some microsoft plans. `Long long'
works about everywhere, except it is neither c89 nor posix compliant, and
it isn't *assured* to never be 128 bits. It is in gnu C and in many others
as an extension. `size_t' or `ssize_t' are better choices, and I
imagine they would be `long long' on P64. Another choice is to just use
"char *", but if the objective is to avoid rewriting existing code...
`ptrdiff_t' does have the theoretical problems pointed out earlier, but in
practice always hold a whole pointer. ptrdiff_t and size_t require c89 but
not posix. Ssize_t requires posix. Both environments are ~~ universal now.
Another question is: how to printf(3) a size_t? C9X has two solutions for
this, one of them will actually work with c89 compilers .. it just needs
new headers. That's a subject for another day, stay tuned...
ross