From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7697 invoked by alias); 14 Jul 2005 05:28:13 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 7635 invoked by uid 22791); 14 Jul 2005 05:28:06 -0000 Received: from rwcrmhc13.comcast.net (HELO rwcrmhc12.comcast.net) (204.127.198.39) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 14 Jul 2005 05:28:06 +0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (rwcrmhc13) with SMTP id <200507140528030150037ffee>; Thu, 14 Jul 2005 05:28:03 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 14 Jul 2005 05:28:00 -0000 Subject: Re: Where does the C standard describe overflow of signed integers? From: Paul Schlie To: Robert Dewar CC: GCC Development Message-ID: In-Reply-To: <42D5C70F.5060109@adacore.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-07/txt/msg00577.txt.bz2 > From: Robert Dewar >> Paul Schlie wrote: >> Although I don't intend to extend the debate; doesn't anyone find it curious >> that given this hard requirement, combined with the fact that all current >> machine architectures rely on 2's complement signed integer representation >> to eliminate the otherwise necessity for distinct signed integer arithmetic >> operations; that by extension unsigned and signed integer arithmetic >> operations are behaviorally equivalent all current machine implementations >> (as well as likely future implementations for the same reasons); > > nonsense! -1/1 = 0 signed, -1 unsigned Actually as -1(signed) == UINT_MAX(unsigned) there's no problem, as 1..1/0..1 == 1..1. Although suspect you meant something like 1/-1. However as 2's complement division typically presumes the effective conversion of signed values to their absolute unsigned values (which is the form in which the division typically takes place, which is itself often further decomposed to conditional modulo unsigned subtractions, and then sign corrected afterward), I don't view this as a discrepancy; but do agree signed division is typically a distinct operation, which wraps sign correction around a fundamentally unsigned division operation; which itself tends to rely on modulo unsigned subtraction at it's core. > -1 < 1 signed, -1>1 unsigned Agreed, however as above, comparison operations are essentially composed of an unsigned modulo subtraction, who's result's high order virtual sign bit determines the logical result of the operation as a function of the xor of it's operand's virtual sign bits. So essentially again just an wrapper over an unsigned modulo subtraction operation. 1..1 - 0..1 == 1..0 => true (signed), false (unsigned) So overall, it seems pretty clear that even these two arguable exceptions actually themselves tend to rely on modulo unsigned arithmetic at their core in all typical implementations of these signed operations.