Style guides and portability

[Doug Gwyn]

In article <1163 at tredysvr.Tredydev.Unisys.COM> paul at 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.