Date: Fri, 31 Oct 2003 16:43:37 +0100 From: Erik Trulsson <ertr1013@student.uu.se> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: current@freebsd.org Subject: Re: Anyone object to the following change in libc? Message-ID: <20031031154337.GA19287@falcon.midgard.homeip.net> In-Reply-To: <200310311506.h9VF6h8T030897@khavrinen.lcs.mit.edu> References: <BAEB9CED-091F-11D8-B483-000393BB9222@queasyweasel.com> <3F9F4FE6.29C4E178@mindspring.com> <3FA0EEFD.431DD759@mindspring.com> <20031030120925.K80335@beagle.fokus.fraunhofer.de> <200310301659.h9UGxAPk023337@khavrinen.lcs.mit.edu> <20031031174658.T3463@gamplex.bde.org> <200310311506.h9VF6h8T030897@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@student.uu.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031031154337.GA19287>