Re: Anyone object to the following change in libc?

<<On Fri, 31 Oct 2003 18:01:34 +1100 (EST), Bruce Evans <bde_at_zeta.org.au> said:

> POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
> integer types exist.  It says that the existence of int8_t implies
> that a byte is 8 bits and CHAR_BIT is 8.  I'm not sure what prevents
> int8_t being smaller than char.

Nothing can be smaller than char (except bitfields, which you can't
take the size of anyway).

The full story:

The POSIX sockets standard (I forget which letter it had) introduced
uint8_t et al, but was aligned to C90.  That amendment was integrated
into the main text at the same time as C99 was, and late in the
process we realized that C99's definition of uint8_t is much stricter
than what the socket standard expected.  (Specifically, the socket
standard allows uint8_t to have padding bits that do not participate
in the domain of the type, but C99 does not.)  Faced with the choice
of having to invent from whole cloth a completely new set of
interfaces to describe packing and unpacking eight-bit network data in
nine- or sixteen-bit characters, or specifying an explicit byte size,
we chose the latter.  It helped that there were no more 36-bit
platforms to be concerned about.  (Some would say that this was a
rather belated recognition of a choice the industry made two decades
ago....  There was, however, a 36-bit implementation of FIPS 151-2, by
UNISYS.)

-GAWollman