What breaks? (was Re: 64 bit longs?)

[Doug Gwyn]

In article <1991Jan18.044948.27943 at zoo.toronto.edu> henry at zoo.toronto.edu (Henry Spencer) writes:
>In article <14890 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>>There is no portable way to declare any integral type constrained to use
>>precisely 32 bits in its representation.  However, "long" portably declares
>>one that has AT LEAST 32 bits in its representation (or, you could express
>>this in terms of the guaranteed range of representable values).  net32_t
>>is hopeless for the first case and unnecessary for the second.
>Uh, Doug, please don't confuse the two slightly different threads of
>discussion here.

But the discussion has bifurcated, and I was responding specifically to that
(which is why there are two distinct cases considered in my posting).

>There is no portable way to declare a type with *exactly* 32 bits, ...

And there is no guarantee that such a type even exists, which is why I
disagree to some extent with ...

>Life with 64-bit longs would be a whole lot easier if the authors of
>certain kernel networking software -- for example -- had consistently
>used a net32_t typedef rather than int and long.

Life would only be easier for systems whose C implementations provided
an integral type of exactly 32 bits.  On the other hand, if the code had
been designed to work anywhere that AT LEAST 32 bits were supported, it
would have made life even easier.  To do the latter it would have
sufficed to use (unsigned) long.  The main advantage of a typedef would
simply be for purposes of encapsulating an abstract data type (netaddr_t,
for example).  While that is important, I want to be sure that nobody
mistakenly believes that it legitimizes building in assumptions about
EXACT sizes for integral representations.