Uses of "short" ?

[Wayne Throop]

> > Even when writing grubby device driver code, you should use C as a
> > higher-level language.
> >         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.
>           Bill Crews

Well, it surely can't be done without refering to C's primitive types,
but I think that it should still be done abstractly.  You need a module
that "knows" about the physical-to-C-types mappings that you need to
use, and there you say

    typedef packet_id_type  short;    /* network needs 16 bits signed */
    typedef packet_len_type unsigned; /* network needs 32 bits unsigned */
    typedef io_register_type long;    /* a 32 bit signed register */
    ... etc, etc

and everywhere else in the code, you refer to the abstract types
packet_id_type, packet_len_type, io_register_type, and so on.  Thus, the
machine-dependant part of things can be kept to a very small part of the
world, by abstracting the machine (or specification) dependant types.

Why is this an advantage?  Because it allows you to have a "handle" on
things that are, say, io_register_type.  If you just declared them
"long" everywhere, you couldn't tell them from file positions, or
other things that might be declared "long".

In this sense, using "long" or "short" or "int" directly is often "too
low level" a use of C.  If you want "a small integer that won't get too
large" use "short".  But if you want "a thing that must be mapped to a
specific size and shape in bits", use an abstract type, not the
(changable) primitive type.  In "real" code for large systems, I'd
hope to almost *never* see *anything* declared to be any primitive
type.
-- 
Wayne Throop at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!rtp47!throopw