long long vs 16-bit machines

[Steve Correll]

dougaresearch.att.com:
>   The supposition that ints in C are 32 bits long is wrong de
>   facto as well as de jure.  There are lots of 16-bit machines
>   out there.
rmsagnu.ai.mit.edu:
>   These programs don't run on the 16-bit machines.  This is a problem in
>   principle, but probably not a big one, because 16-bit machines are
>   obsolete except in embedded systems.

I suppose you could consider an IBM-compatible PC running MS-DOS to be an
embedded system.

As a denizen of the "obsolete" world of 16 bits, I think the arguments
favoring a new data type called "long long" apply as well here as in the 32-bit
world. Certainly PC programmers are no less capable of writing sloppy code, and
though they quickly learn that "int" differs from "long", nothing in the
environment (see the table below) has prevented them from lapsing into the
comfortable (albeit questionable) assumptions that "long means 32 bits" and
"long is just big enough to hold any pointer" (see the table below). When and
if PC compilers support 64-bit integers, a conservative approach would leave
"long" at 32 bits and add "long long".

Dictating the sizes of "long" and "long long" is probably a mistake, because
even after you have decided to cater to existing sloppy code, you may choose
different sizes depending on the environment (machines with 32-bit pointers
and 64-bit registers may prefer that "long" remain 32 bits, whereas machines
with 64-bit pointers and registers may prefer that "long" and "long long" both
be 64 bits). But it would be useful to standardize the existence of "long long"
and the requirement that it be at least as large as "long". That would also
recognize existing practice by Amdahl, GCC, and others.

		MS-DOS			OS/2
int		16			32
long		32			32
T *		16 (sometimes 32)	32 (sometimes 16)