Scott Reynolds wrote:
>It's my understanding that one should only code intNN_t types when one 
>needs _exactly_ NN bits, and a more generic type (e.g. quad_t) when 
>needing one that is _at least_ some number of bits.  The only times that 
>I see a need for the intNN_t types are in pieces of code that deal 
>with standards (networking, most notably) and hardware drivers.  Of 
>course, it's very important in those instances.

I second that.  I've just been through another round of updating my
16-bit port of the db(3) code to the latest version.  Only, this time
it was worse due to the, IMHO, misguided use of the intNN_t types in
the mainstream source.  Not even did the use of these types break a
possible big-endian 16-bit port, it also caused a performance penalty
for 32-bit processors.

In my experience, their only use is in dealing with external data
representations.  In mainstream code you are better off defining
"functional" types with meaningful names (like caddr_t, daddr_t,
time_t, pgno_t, etc.) and ensure that they are big enough.  With a bit
of work this can be mostly automatic, even.

>On the flip side, code that uses quad_t should only assume that it has at 
>least 64 bits, or that a long has at least 32 bits; the problems that 
>appear otherwise are quite well known by now. :-)

Judging from this thread, apparently not.

And we haven't mentioned the 32-bit Transputers, yet, where there is no
such thing as a int16_t.

-- 
Christoph Badura	bad@flatlin.ka.sub.org		Wk +49 228 97024-36

Es genuegt nicht, keine Gedanken zu haben;
man muss auch unfaehig sein, sie auszudruecken.  - Karl Kraus