From owner-freebsd-current@FreeBSD.ORG Sun Jul 13 12:29:45 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 504CD37B401 for ; Sun, 13 Jul 2003 12:29:45 -0700 (PDT) Received: from smtpout.mac.com (A17-250-248-86.apple.com [17.250.248.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAC4B43FAF for ; Sun, 13 Jul 2003 12:29:44 -0700 (PDT) (envelope-from leimy2k@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h6DJTWCR025561; Sun, 13 Jul 2003 12:29:32 -0700 (PDT) Received: from mac.com (adsl-78-178-166.jan.bellsouth.net [216.78.178.166]) (authenticated bits=0) by mac.com (Xserve/8.12.9/MantshX 2.0) with ESMTP id h6DJSdsq016525; Sun, 13 Jul 2003 12:29:17 -0700 (PDT) In-Reply-To: <20030713190720.GA17305@falcon.midgard.homeip.net> 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> <20030713190720.GA17305@falcon.midgard.homeip.net> Mime-Version: 1.0 (Apple Message framework v578) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <340CBBD2-B568-11D7-BE3B-0003937E39E0@mac.com> Content-Transfer-Encoding: 7bit From: David Leimbach Date: Sun, 13 Jul 2003 14:28:38 -0500 To: Erik Trulsson X-Mailer: Apple Mail (2.578) 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:29:45 -0000 > > 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. > So for the one way conversion of signed to unsigned it will behave like 2's compliment all the time. What about back to signed? I assume that it defaults back to the platform's implementation of the signed type.... which due to the conversion to unsigned would also, logically, be encouraged to behave as a 2's compliment signed number. Cute way to make the standard "seem" flexible. The overhead of type conversion is often overlooked in coding it seems... On some platforms like the PPC going from int to float takes a lot longer than one might think... but that is another story :). [no need to answer this... unless we take it out of this thread] > 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. > No arguments here. :) Sorry if we wandered off too far. It was at least enlightening for me and hopefully others. Dave > > -- > > Erik Trulsson > ertr1013@student.uu.se