From owner-freebsd-current@FreeBSD.ORG Sun Jul 13 14:07:10 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 834E237B404 for ; Sun, 13 Jul 2003 14:07:10 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09C6943F3F for ; Sun, 13 Jul 2003 14:07:09 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id HAA28993; Mon, 14 Jul 2003 07:06:41 +1000 Date: Mon, 14 Jul 2003 07:06:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Erik Trulsson In-Reply-To: <20030713190720.GA17305@falcon.midgard.homeip.net> Message-ID: <20030714064714.U5639@gamplex.bde.org> References: <20030713000559.28c18be6.kabaev@mail.ru> <20030713044331.GA89785@crodrigues.org> <20030713.122352.22176834.imp@bsdimp.com> <20030713190720.GA17305@falcon.midgard.homeip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: rodrigc@crodrigues.org cc: kabaev@mail.ru cc: freebsd-current@freebsd.org cc: jilles@stack.nl cc: "M. Warner Losh" Subject: Re: GCC 3.3.1, new warnings with 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: Sun, 13 Jul 2003 21:07:10 -0000 On Sun, 13 Jul 2003, Erik Trulsson wrote: > On Sun, Jul 13, 2003 at 01:37:32PM -0500, David Leimbach wrote: > > You keep saying this... where is this "must behave as two's compliment > > stated?" > > > > >(unsigned int) -1 == 0xffffffff (assuming 32-bit int). > > > > or with a valid one's compliment C99 compliant system > > (unsigned int) -1 = 0xfffffffe; > Only if UINT_MAX happens to be0xfffffffe, which it probablky won't be. Probabilty zero on C99 conformant systems :-). UFOO_MAX is (2^N - 1) where N is the number of value bits in the representation of type FOO. See 6.2.6.2. (UFOO_MAX may still be represented differently in memory than as N lower bits all set.) [Someone wrote] > > >even on a one's complement's machine, without the standard conversion, > > >the 'type punning' conversion of -1 would yield 0xfffffffe, which is > > >still > 0. > > > > > Correct :). I still don't think C enforces two's compliment. I don't think there is any requirement that the layout of the bits in representations of unsigned types has anything to do with the layout for signed types, so type punning might set implementation-specific wrong {value, trap, padding} bits. Bruce