Seeing as we don't (yet) have available a tonnage of 64-bit platforms
(as opposed to the sheer numbers of 32-bit boxes out there), I think that
perhaps 'long long' (should we call it 'quad', or has someone done
this ages ago?) should stick around just a bit longer.

Then there is also the problem that even the existing 64-bit platforms
maintain some 32-bit stuff, as cgd pointed out.  Besides that, since
"int" is supposedly the most efficient type for the machine to handle
(didn't K&R say something about that?), on a 64-bit machine, we would
then have {short=16, int=64, long=64}.  What if we want to use 32-bit
ints?  Do we take a performance hit and start using 'q &= 0xffffffff'
every time we want to use a 32-bit quantity, or do we stuff two 32-bit
ints into a 64-bit-aligned structure and dereference them that way
{that's C and not asm, I know, but...}?  Or do we just take a memory
hit and use all 64-bit quantities and toss 32-bit completely out the
window?  I mean, yes, having the upper limit at 64 bits is way cool
considering how many bytes etc. of data one can now access, but the
space penalty for executables to me just seems really extreme (unless
the machine uses 32-bit instructions and 64-bit data or something).

The current scheme of {short=16, int=16/32 <machine-dependent>, long=32}
is something I think we're stuck with for a while until the 32-bit fiddling
by 64-bit machines, especially with regards to pointers, goes away.

Unless, of course, I Missed Something... :-)

[Please don't bash me; I'm only trying to make a few observations based
on the information I have seen here.  I don't write compilers, nor have
I had experience with 64-bit platforms.  The current state of affairs just
seems to dictate that we stick with what *currently* works until the
64-bit expansion really happens.]



				--*greywolf;
--
If anyone requests a reason as to why Windows NT is inferior to UNIX,
refer them to the process scheduler, for starters.  Of course, users
don't care, and programmers try not to, even though they both should.
If that fails, reiterate that remote administration and control of a
node is a *good* thing, especially if network security is concerned.