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 <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). 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 > UNISYS.) -- <Insert your favourite quote here.> Erik Trulsson ertr1013_at_student.uu.seReceived on Fri Oct 31 2003 - 06:43:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:27 UTC