Style guides and portability
Doug Gwyn
gwyn at smoke.brl.mil
Sat Jan 12 10:03:32 AEST 1991
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.
More information about the Comp.lang.c
mailing list