From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 07:43:42 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4220616A4CE for ; Fri, 31 Oct 2003 07:43:42 -0800 (PST) Received: from falcon.midgard.homeip.net (h76n3fls24o1048.bredband.comhem.se [213.67.148.76]) by mx1.FreeBSD.org (Postfix) with SMTP id 5D58A43FAF for ; Fri, 31 Oct 2003 07:43:39 -0800 (PST) (envelope-from ertr1013@student.uu.se) Received: (qmail 34251 invoked by uid 1001); 31 Oct 2003 15:43:37 -0000 Date: Fri, 31 Oct 2003 16:43:37 +0100 From: Erik Trulsson To: Garrett Wollman Message-ID: <20031031154337.GA19287@falcon.midgard.homeip.net> Mail-Followup-To: Garrett Wollman , Bruce Evans , current@freebsd.org References: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310311506.h9VF6h8T030897@khavrinen.lcs.mit.edu> User-Agent: Mutt/1.5.4i cc: current@freebsd.org Subject: Re: Anyone object to the following change in libc? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 15:43:42 -0000 On Fri, Oct 31, 2003 at 10:06:43AM -0500, Garrett Wollman wrote: > < 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.) -- Erik Trulsson ertr1013@student.uu.se