> It is permissible for
> an int to be 16 bits, 32 bits, or, as on the Alpha, 64 bits.   It is
> permissible for sizeof (long) to be less than sizeof (int),

You meant, I assume, "sizeof (int) to be less than sizeof (long)", since
what you typed is, in fact, impermissible.

There is also no guarantee in the Standard that "long" is the longest
integral type, though any longer types ought to at least conform to the
Standard in reasonable ways ("long long" is a syntax error, damnit!),
and none of the types documented in the Standard (size_t etc) may be
types other than char, short, int, or long.  (or unsigned versions as
appropriate)

There is an implicit promise, courtesy of the mystical "spirit of C", that
"long" is at least an efficient data type, though not the fastest natural
data type of a machine.  It is thus unnatural for "long" to be 64 bits on
a 32-bit machine.

Code that assumes that pointers can be stuffed into longs, ints, or indeed
any integral type whatever is just plain broken with respect to portability,
and there are shockingly few instances where it's justified.  And the idea
of easing the "portability" of such broken programs onto 64-bit machines by
slowing down the vast majority of programs on 32-bit machines by declaring
that "long" is 64 bits is just plain wierd.

The current arrangement (char=8, short=16, int=32, long={32 or 64, depending
on datapath width}) is perfectly reasonable.  Let's find more appropriate
ways to plan for the future.