In message <199912220123.RAA01028@random.teraflop.com>, Ross Harvey writes:
>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.

It's very, very, hard - look at the Linus vs. RMS flamewar in gnu.misc.discuss
a while back about Emacs.  As Linus pointed out, the only *safe* thing to do
is write a "port" of the program that uses something other than
pointer/integer magic (e.g., put pointers in structs along with tag data
for lisp), and use that on any platform you don't know for sure works.

>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.)

I think there are Alpha systems (none of ours, probably) that use 32-bit
pointers for most software, but 64-bit longs or long longs.

>        P64     a totally lame environment "thought" up by microsoft, where
>                only pointer and long long are 64 bits

Not unique to them; I think SGI was doing it for a while.

>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...

The canonical way to printf a size_t:
	%ld	...	(long) foo
ugly, but it will work on "probably everything you care about".

-s