From owner-freebsd-current@FreeBSD.ORG Sun Jul 13 12:40:30 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 9109137B401 for ; Sun, 13 Jul 2003 12:40:30 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF81F43F3F for ; Sun, 13 Jul 2003 12:40:20 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h6DJeIcF002275; Sun, 13 Jul 2003 13:40:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 13 Jul 2003 13:40:13 -0600 (MDT) Message-Id: <20030713.134013.126911283.imp@bsdimp.com> To: leimy2k@mac.com From: "M. Warner Losh" In-Reply-To: <1046B4F9-B561-11D7-BE3B-0003937E39E0@mac.com> References: <20030713152154.GA96653@stack.nl> <20030713.122352.22176834.imp@bsdimp.com> <1046B4F9-B561-11D7-BE3B-0003937E39E0@mac.com> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org 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:40:30 -0000 In message: <1046B4F9-B561-11D7-BE3B-0003937E39E0@mac.com> David Leimbach writes: : You keep saying this... where is this "must behave as two's compliment : stated?" Read the fine print on the signed to unsigned conversion and you find that it must be done modulo 2^N. Also, I never stated that the standard requires the machine use two's complement representation, but it has to behave as if that were the case. >From the standard: 6.3.1.3 Signed and unsigned integers [#1] When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged. [#2] Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type. The argument runs like this: o assume int is 32 bits, but the argument can be run for other word sizes. o the largest value is 0xffffffff. largest plus 1 is 0x100000000. o -1 increased by 'one more than the maximum value' is 0xffffffff. That's behaving as if the type was two's complement. : > (unsigned int) -1 == 0xffffffff (assuming 32-bit int). : : or with a valid one's compliment C99 compliant system : (unsigned int) -1 = 0xfffffffe; That's an invlaid conversion. While -1 might be represented by the bit pattern 0xfffffffe, "(unsigned int) -1" must evaluate to 0xffffffff. : > 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. You are partially right. An 'int' containing '-1' might have a bit pattern of 0xfffffffe or even 0x800000001, but converting it to 'unsigned' must result in 0xffffffff. Warner