Uses of "short" ?

[Guy Harris]

> You are invited to write a 3Com Ethernet driver that works on a PC
> (16-bit int) and on a Cyb machine (32-bit int) without referring to longs
> or shorts.  I.e., a 16-bit hardware register is a 16-bit hardware register,
> despite your desire for abstraction.

The object being described is a 16-bit hardware register.  As such,
technically, there's no abstract way to describe it in C except *maybe* a
bitfield.  What happens on an 18-bit machine?  One hopes that 1) the
register is an 18-bit register and 2) "short" is 18 bits on the machine (or
that both are 36 bits).

For that matter, what if the board has memory-mapped I/O on one machine, but
not on another (i.e., you have to issue I/O instructions to read the device
registers)?  If you truly want a portable driver, you'll have to pick a
level of abstraction *above* the device registers and have 99% of the code
in the driver deal with that abstraction rather than the device registers.

The Ethernet driver has to deal with a lot of objects that aren't part of
the board - a 4.2 driver, for instance, has to talk to the various protocol
modules above it.  That code doesn't have to get up-close and personal with
the machine to the degree that code that fiddles hardware registers does.

Also, if you can find *any* statement where I say that the use of "short"
and "long" violates proper use of abstractions, and should be avoided, I'd
really like to see it.  In fact, I believe quite the opposite.  In some
cases, "int" better fits the abstract object being described than "short" or
"long" does, and in some cases "short" or "long" better fit it.
"short" and "int" capture a requirement that -32767 to 32767 be the range of
values of this (integral) object equally well.
However, "short" specifies the amount of space required more stringently
than "int" does, and "int" (sort of) specifies the required efficiency for
instructions that manipulate the object better than "short" does.  Choose
the one that specifies the part you *do* care about (and in the case of a
16-bit device register, "short", while *not* perfectly specifying this, does
so better than "int" does).  If you want something that has a range of
values of -2147483647 to 2147483647 (*not* -2147483648 - the Sperry 100
users will get a bit annoyed if you assume that all UNIX machines can
represent -2147483648), you should use "long", even if you "know" that
you'll be running on a machine with 32-bit (or wider) "int"s.

> I nevertheless believe, for instance, that when Internet protocol specifies
> that the header checksum is a 16-bit 2's-complement number, it is wise to
> comply, if you want the packets to fly properly.

So, if your language has a primitive integral data type that specifies that
objects of the type are 16 bits and that arithmetic is done in 1's
complement (not 2's complement - check the IP spec again), use it.  There is
no way in C to say "I want a 16-bit 1's complement number."  (Note that the
4.2BSD VAX and Sun IP checksum routines both drop into assembler language at
times.)

	Guy Harris