From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 07:06:47 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 CD3DA16A4CE for ; Fri, 31 Oct 2003 07:06:47 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3D4A43FBD for ; Fri, 31 Oct 2003 07:06:46 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h9VF6iDa030900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Fri, 31 Oct 2003 10:06:45 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h9VF6h8T030897; Fri, 31 Oct 2003 10:06:43 -0500 (EST) (envelope-from wollman) Date: Fri, 31 Oct 2003 10:06:43 -0500 (EST) From: Garrett Wollman Message-Id: <200310311506.h9VF6h8T030897@khavrinen.lcs.mit.edu> To: Bruce Evans In-Reply-To: <20031031174658.T3463@gamplex.bde.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> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 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:06:47 -0000 < 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