On Fri, Oct 31, 2003 at 10:06:43AM -0500, Garrett Wollman wrote:
> <<On Fri, 31 Oct 2003 18:01:34 +1100 (EST), Bruce Evans <[EMAIL PROTECTED]> 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).

Perhaps not smaller in terms of the sizeof operator, but why can't one
have a 16-bit char, and an int8_t which occupies 16 bits, but only uses
8 of them - the other 8 being padding?

> 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

Where in C99 does it say that uint8_t can't have padding bits?
I can't find anything in n869.txt to that effect.
As far as I can tell, the only type that is not allowed to have any
padding bits or trap representations is unsigned char.

> 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

<Insert your favourite quote here.>
Erik Trulsson
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to