lint, pointers, 0 (what else?)

[mwm at ucbtopaz.CC.Berkeley.ARPA]

In article <282 at talcott.UUCP> tmb at talcott.UUCP (Thomas M. Breuel) writes:
>> Re: int8, int32, etc.
>> Do you also propose int9, int36?  int24?  float48?
>> Let's not embed machine dependencies into the language!
>
>Some real-life programs require minimal sizes for integers and floating
>point numbers. 'int8' should be used as an integer type that holds at
>least 8 bits, not as a type that holds exactly 8 bits.
>
>If your 'C' compiler does not support 32 bit integer precision, but
>my differential equations need 32 bit integers, then that is a problem
>with your 'C' compiler, not my equations.

You pegged int 8 almost exactly (I want it to have 8 bits of magnitude).
Likewise, uint10 should be an unsigned holding 10 bits. So, if I need an
int that holds -511..511, I should declare it as int9. By leaving out that,
you are forcing systems that have 10-bit quantites "naturally" (is BBN
still selling them?) to go to the next size you typedef'ed.

Conclusion: For any machine/compiler pair, there should be a file that
typedefs intX and uintX for all X the machine can use so that you get at
least that many bits. X's to big for the system are left undefined. You may
want two versions, one optimized for space, and one optimized for speed.

As recently suggested, there should also be a point typedef, that is large
enough to hold the difference between two pointers.

The result of using this system is that you know your programs will get
enough space on strange hardware. If it needs things that are too big, it
won't compile.

	<mike