Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rtp47.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!rti-sel!rtp47!throopw
From: throopw@rtp47.UUCP (Wayne Throop)
Newsgroups: net.lang.c
Subject: Abstraction
Message-ID: <199@rtp47.UUCP>
Date: Fri, 27-Sep-85 14:36:51 EDT
Article-I.D.: rtp47.199
Posted: Fri Sep 27 14:36:51 1985
Date-Received: Sun, 29-Sep-85 06:35:44 EDT
References: <1390@brl-tgr.ARPA> <2778@sun.uucp> <519@lasspvax.UUCP> <2803@sun.uucp> <5569@fortune.UUCP>
Organization: Data General, RTP, NC
Lines: 38

In the "short vs int vs long" discussion, a topic comes up that I'd like
to comment on.  To review:

> >>  But I can't quite fiqure out what you mean here.  Does it mean that
> >>  is if 'short' 'int' and 'long' are the same size then I should
> >>  choose something other than 'int'?
>
> >   You did figure out what I meant - that is exactly what I mean!  If
> >   you want to have a variable that can hold values outside the range
> >   -32767 to 32767, use "long", regardless of whether something else
> >   just might happen to work.
>
> If one is very concerned about portability to other-wordlength machines, why
> not use typdefs like:
>
> 		typedef int bit16;
> 		typedef long bit32;
>
> Then make all your declarations as bit16, bit32, etc.
>
>               Robert Clark

Good idea.  But beware of using these when what you mean is not what
the typedef implies.  In particular, many implementers typedef physical
layouts as above when what they really want to abstract is *not*
physical layout, but something else again.

For example, on a Unix(tm) system, should one declare a variable to hold
a process id as a bit16, and is that more "abstract" than defining it
"short"?  I maintain that "proper" use of C would typedef (or #define)
an abstract handle for "pid_type", and then declare variables that hold
pids to be the abstract type.

Thus, "bit16", "bit32", and the like are good ideas, but beware.  These
names should *only* be used where physical layout is the major concern
(that is, almost nowhere).
-- 
Wayne Throop at Data General, RTP, NC
!mcnc!rti-sel!rtp47!throopw