Uses of "short" ?

[Guy Harris]

> Well, yes, to my mind. The programmer, thinking abstractly about a
> particular process, is likely to think of a variable quantity as
> an integer or as a real.

Which is a dangerous pattern of thought.  "int"s don't behave like integers
- you were never guaranteed that an "int" could hold numbers outside the
range -32768 to 32767 (the first C implementation, remember, was on a 16-bit
machine) and "float"s and "double"s definitly don't behave like real numbers
(otherwise, there wouldn't be a discipline called "numerical analysis").
Given that the maximum absolute value which an "int" can hold is fairly
small, it's not particularly safe to ignore considerations of range (it's
not safe to ignore considerations in precision - in "real"s -either, but
integers are always precise).

Furthermore, if this variable quantity is to be used as, say, an array
subscript, if the range of valid values for that quantity is a primary
consideration that program stands a good chance of getting a subscript range
exception or a wild reference.

> In practice, the programmer usually will have a pretty good idea when a
> quantity is likely to violate that default assumption on a particular
> machine

I don't want them to have a pretty good idea when it's going to violate that
default assumption on a particular machine.  I want them to have a pretty
good idea when it's going to violate that default assumption on a
16-bit-"int" machine; then there won't be so much d*mn code out there that
needs a good going-over by "lint" before it'll run on PDP-11s and
8086-family-chip based machines (or before it'll handle files, or other
objects not constrained by the address space, bigger than 64KB on such
machines.

> Now we're going to have a C standard pretty soon, in all probability,
> and that may well change the default assumptions.  If "int" is
> truly defined as a 16bit quantity, I will probably change my
> default working habits to use long -- otherwise my default
> abstraction would be violated too often.

Sorry, "there wasn't a rigorous enough standard for C until recently" is not
an excuse for using "int" to hold quantities which could, conceivably, be
outside the range -32768 to 32767.  K&R states quite clearly that "int"
takes up 16 bits on PDP-11s, so there exists at least one (very popular)
machine on which the "default assumption" about "int" would be violated.
Given the number of PDP-11s (and IBM PCs) out there, that assumption is
going to be violated quite often.  Even before the ANSI C standard
explicitly stated that you cannot count on an "int" holding values outside
that range (it does *not* "define it as a 16bit quantity"; it defines it as
a quantity which *may* hold values outside the range that fits in a 16-bit
quantity, but which is not *guaranteed* to be able to hold values outside
that range), it was unsafe and bad practice to so use "int".  (Consider all
the postings that say "our news system truncates items with more than 64KB,
so could you please repost XXX" for an example of why it is a bad practice.)

> Up until the present, however, we have been working with a language in
> which the definition of short, int, and long were specifically machine
> dependent, and anyone porting software simply had to be aware
> of the obvious places where machine dependencies showed up.

They're *still* machine-dependent; however, some of the constraints on them
that were implicitly stated by the enumeration of C implementations in K&R
are now stated explicitly.  People *porting* software shouldn't have to be
aware of those places.  People *writing* software - even if they "know" that
it'll never be ported - should be aware of them.  Unfortunately, the people
doing the porting get stuck with cleaning up after the mess left by the
original author, and those people may have no way to force the original
author to fix the problem for them.

> > Code that uses "int" to implement objects known to have values outside
> > the range -32767 to 32767 is incorrect C.  The ANSI standard explicitly
> > indicates this.  Even in the absence of such an explicit indication in
> > an official language specification document, this information should be
> > imparted to all people being taught C.
> ----------
> Now that there is a reasonably firm draft standard, this is a reasonable
> statement.  Not very long ago it was religious dogma.

Hogwash.  If you write code that assumes an "int" can hold things outside
that range, you should put something like

	#ifdef pdp11
		FORGET IT, NO WAY, GIVE UP AND GO HOME
	#endif

to emphasise that this code will not run on a PDP-11.  Not very long ago K&R
stated that "int" was a 16-bit quantity on the PDP-11.  At the very least,
people writing that code should acknowledge the fact that it won't work on a
PDP-11 (or IBM PC, or...).  If they'd read the C Reference Manual in K&R,
they'd have known that even before there was an ANSI standard.

	Guy Harris