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