> Yes, and they're dead wrong. Code that assumes sizeof(long) ==
> sizeof(int) is /not/ portable,

"Portable" is not a boolean; it's not "it is portable or it isn't".
Portability is a matter of degree.  For example, the standard allows
ints to be as small as 16 bits, yet there's plenty of code running
around that assumes they're larger than that, code which is "portable
enough": portable to all the platforms its maintainer(s) care(s) about.

If I'm writing, say, a console serial line driver for a VAX, I don't
mind assuming things like little-endian 32-bit two's-complement integer
arithmetic.  If I'm writing a SPARC memory test program, I don't mind
assuming int is at least 32 bits (or exactly 32, if I don't expect to
care about sparc64).  If I'm writing a shell, I may not be willing to
make those assumptions, but I may make others, such as assuming that I
have certain aspects of POSIX sessions available.

Code that assumes ints and logs are the same size may be portable
enough for its target audience.  Other code that makes the same
assumption may not be.

I've actually contemplated building a "compiler"/runtime which goes out
of its way to break the various common assumptions that are true
"everywhere" but which are not promised, specifically as an aid to
increasing code portability.  (For example, I might do 9-bit chars,
18-bit ints, 36-bit longs, a 27-bit address space that addresses things
in 36-bit units, 27-bit pointers to large objects and bigger pointers
to smaller-than-long objects, sign-magnitude integer arithmetic, and
the bits of the chars that make up ints and longs interleaved in ways
that cannot be described as any of the common endiannesses.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B