Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Style guides and portability
Keywords: style guide, Thomas Plum, portability
Message-ID: <14824@smoke.brl.mil>
Date: 11 Jan 91 23:03:32 GMT
References: <1163@tredysvr.Tredydev.Unisys.COM>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 23

In article <1163@tredysvr.Tredydev.Unisys.COM> paul@tredysvr.Tredydev.Unisys.COM (Paul Siu) writes:
>While looking through Thomas Plum's style guide, I notice he mention that one
>should set up a seperate #define file for data types.  The file will contain
>data types such as ushort for unsigned 8-bit numbers, and your program will use
>only the data types define in this file.  He justify this by saying that normal
>C datatypes varies from machine to machine, an int for example can be 8-bit,
>or 16-bit depending on machines.  The only time you should use int is on
>function returns values.

No, any C compiler worth using (and certainly any that conforms to the
standard) will provide at least 16 bits for an int, at least 32 bits
for a long, and at least 8 bits for a char.  While there are uses for
user-defined primitive data types (for example, I use "bool" and
(generic object) "pointer" types), I don't think that int16, int32, etc.
are justifiable.

It is possible that you might have to deal with a C environment that
simply doesn't support "unsigned char", in which case you might need
to devise some kludergy to cope with the situation.  However, the only
basic type I know of that you are likely to encounter problems with is
"signed char".  There is no exact equivalent for this in many C
implementations.  The simplest way to deal with this is to never try
to write code that depends on "signed char"; it can always be avoided.