integer types, sys calls, and stdio

[mwm at ucbtopaz.CC.Berkeley.ARPA]

In article <294 at psivax.UUCP> friesen at psivax.UUCP (Stanley friesen) writes:
>	Whitesmith has come up with a series of defined types
>which can be used to increase portibility if they are used regularly.
>They are defined in an include file "std.h" which can be adjusted
>to each machines oddities. The types, and intended meanings are:
>[list deleted - mwm]

Stanley, this list is similar (in intent, anyway) to
/usr/include/sys/types.h.  types.h has the advantage that it doesn't tie
you to some specific architecture.  DRI pushes similar things with their
compilers, that define "BYTE" (8 bits), "WORD" (2 bytes) and "LONG" (4
bytes). My basic reaction to all of these is the same: YUCH.

Not that these things are bad, just that they aren't sufficient if you're
really worried about it (for instance, how does the 7-bit chars used for
TOPS-10 ASCII fit? Better yet, how about their 6-bit chars used in some
places?).

The correct solution to making sure that you have enough space for all your
int's has already been suggested: A machine-specific series of typedefs of
the form:

typedef	<integer type> sintX ;
typedef <unsigned integer type> uintX ;

Where X is the number of bits of magnitude that you need, sint is a
smallest integer signed type with that many bits of magnitude or more, and
uint is the analogous unsigned integer type (no, we will *not* worry about
trinary machines and other such oddities. Yet.)

Note that for an 8-bit architechture where the compiler makes "char" signed
and does the least suprising thing with "unsigned char", "typedef char
uint8;" works, but you have to have "typedef short sint8" to get 8 bits of
magnitude out of the thing.

Trouble is, one system (4BSD, or AT&T even) introducing that include file
doesn't help much. Old programs would still not use it, and new programs
would require you to create the include file of typedefs.

Having been to lazy to do that, I use the folloing rules:  Most of the
time, If you're not worried about how big integer types are, use int. God
help you if your int's are only 8 bits long (I don't think anyone has done
that). If you need more than 16 bits, use "long".  Never use char as
something to hold an integer - use short for very small objects where
you're worried about space. While not perfect, it doesn't create problems
on screwy machines like the whitesmith/DRI plan, and comes close to working
almost everywhere. Now, if only I could convince the compiler to do runtime
overflow checking.

	<mike