From owner-freebsd-current@FreeBSD.ORG Sun Jul 13 12:07:25 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 8A48237B401 for ; Sun, 13 Jul 2003 12:07:25 -0700 (PDT) Received: from falcon.midgard.homeip.net (h76n3fls20o913.bredband.comhem.se [213.67.148.76]) by mx1.FreeBSD.org (Postfix) with SMTP id 32D5E43F75 for ; Sun, 13 Jul 2003 12:07:23 -0700 (PDT) (envelope-from ertr1013@student.uu.se) Received: (qmail 17341 invoked by uid 1001); 13 Jul 2003 19:07:20 -0000 Date: Sun, 13 Jul 2003 21:07:20 +0200 From: Erik Trulsson To: David Leimbach Message-ID: <20030713190720.GA17305@falcon.midgard.homeip.net> Mail-Followup-To: David Leimbach , "M. Warner Losh" , rodrigc@crodrigues.org, kabaev@mail.ru, freebsd-current@freebsd.org, jilles@stack.nl References: <20030713000559.28c18be6.kabaev@mail.ru> <20030713044331.GA89785@crodrigues.org> <20030713152154.GA96653@stack.nl> <20030713.122352.22176834.imp@bsdimp.com> <1046B4F9-B561-11D7-BE3B-0003937E39E0@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046B4F9-B561-11D7-BE3B-0003937E39E0@mac.com> User-Agent: Mutt/1.5.4i 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 19:07:25 -0000 On Sun, Jul 13, 2003 at 01:37:32PM -0500, David Leimbach wrote: > > On Sunday, July 13, 2003, at 1:23PM, M. Warner Losh wrote: > > >: > 134 #define __glibcpp_signed(T) ((T)(-1) < 0) > >: #define __glibcpp_signed(T) (!((T)(-1) > 0)) > > > >Why not the simpler: > > > >#define __glibcpp_signed(T) ((T)(-1) <= 0) > > > >that way we have an overlap on the range of the two types, so we won't > >get a warning. We know for a fact that -1 != 0 for all known machine > >types (all machines are two's complement, or are required to behave as > >if they are two's complement, per the standard). > > > > 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. For all C99 compliant systems you have that: (unsigned int) -1 == UINT_MAX > > > > >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. C doesn't require two's compliment, but it encourages it. If you take a signed value and convert it to the corresponding unsigned type , the result must be equal modulo 2^N to the original value (where N is the number of bits in the unsigned type. (Ignoring any padding bits.)) (Actually it is modulo a value one greater than the largest value representable by the unsigned type, but this amounts to the same thing.) This means that -1 converted to an unsigned type will always be the largest number representable by that unsigned type. This is true regardless of how negative numbers are represented. For two's complement there is no need to change the representation when converting signed to unsigned values, while this can be needed when using sign-magnitude or one's-complement. And to answer the original question: It is valid to assume that -1 converted to an unsigned integer type will never be equal to 0. -- Erik Trulsson ertr1013@student.uu.se