Uses of "short" ?

[Mike I'll be mellow when I'm dead Meyer]

In article <2032 at brl-tgr.ARPA> gwyn at brl-tgr.ARPA (Doug Gwyn <gwyn>) writes:
>> typedef	long	int60 ;		/* or whatever the type is for 60 bit ints */
>
>My point is, if more than 32 bits are needed then this code is
>not going to port anyway, no matter what typedefs you use.

If it's gotta be ported, then a port will consist of chasing down all the
really long variables, and replacing expressions that use them with the
appropriate calls on the mp library. It'd be nice if those variables were
tagged for you.

If it doesn't *have* to be ported, it would be nice if it wouldn't compile,
so that you avoid the possibility of getting bogus answers. Admittedly, this
problem could be solved by a C compiler that trapped integer overflows.
Anybody got one :-).

>> Likewise, if *your* code uses int8/int16/whatever correctly, specifying the
>> number of bits needed, then there file of typedefs will get them a
>> reasonable type for those variables.
>
>If you use the proper C data types, there will be no need to worry
>about this at all; the code will work on all standard-conforming
>implementations without any change whatsoever.  There is no need
>to invent system-specific typedefs for any integer type through 32
>bits, and for longer integer types typedefs are not sufficient.

You missed the key word, "reasonable." It's unreasonable to declare a large
array with types twice as large as they need to be. Its non-portable to use
the builtin name for the type of reasonable size. Ergo, a typedef that says
what size it is, and a standard file that turns those typedefs into the
correct builtin type for that machine. This allows for both reasonable and
portable code.

	<mike