From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24695 invoked by alias); 4 Dec 2009 20:07:23 -0000 Received: (qmail 24685 invoked by uid 22791); 4 Dec 2009 20:07:22 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Dec 2009 20:07:17 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id nB4K70Ow001528; Fri, 4 Dec 2009 14:07:00 -0600 Received: (from apache@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id nB4K6ngO001522; Fri, 4 Dec 2009 21:06:49 +0100 Received: from 84.105.60.153 (SquirrelMail authenticated user segher) by gate.crashing.org with HTTP; Fri, 4 Dec 2009 21:06:49 +0100 (CET) Message-ID: <55159.84.105.60.153.1259957209.squirrel@gate.crashing.org> In-Reply-To: <87ocmese77.fsf@mid.deneb.enyo.de> References: <5c6f2a5d0911291151j46dc9d28h568b87f57228b28e@mail.gmail.com> <87ljhpt5lu.fsf@mid.deneb.enyo.de> <5c6f2a5d0911291400t63b84bdak3c37b8523040c50c@mail.gmail.com> <87fx7w4iyi.fsf@mid.deneb.enyo.de> <5c6f2a5d0911300726r7b902fdeuf905f698c55407f2@mail.gmail.com> <87my23nasp.fsf@mid.deneb.enyo.de> <29bd08b70911301639u70eeb87xa49e6c92740817c2@mail.gmail.com> <5c6f2a5d0912010300k49636f40l693db2c206dfc3d9@mail.gmail.com> <87ljhm8lga.fsf@mid.deneb.enyo.de> <4B163525.8010104@redhat.com> <873a3qvaan.fsf@mid.deneb.enyo.de> <4B195E8A.90304@redhat.com> <87ljhituan.fsf@mid.deneb.enyo.de> <55131.84.105.60.153.1259956074.squirrel@gate.crashing.org> <87ocmese77.fsf@mid.deneb.enyo.de> Date: Fri, 04 Dec 2009 20:34:00 -0000 Subject: Re: Efficient detection of signed overflow? From: "Segher Boessenkool" To: "Florian Weimer" Cc: "Segher Boessenkool" , "Andrew Haley" , "Mark Dickinson" , "Lawrence Crowl" , "me22" , "GCC-help" User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2009-12/txt/msg00107.txt.bz2 >>> The comment is wrong. The code checks for signed overflow, but the >>> following assignment still overflwos when ux is larger than INT_MAX. >> >> No, it doesn't. This conversion is implementation-defined (6.3.1.3/3), >> and GCC does the obvious two's complement thing. This code is fine. > > It's fine with GCC 4.4, and likely with GCC 4.5 as well. But what > about GCC 4.6? And how will a user compiling third-party software > notice the discrepancy (if it ever arises)? Implementation-defined means the implementation defines the behaviour, and GCC defines it like this: * `The result of, or the signal raised by, converting an integer to a signed integer type when the value cannot be represented in an object of that type (C90 6.2.1.2, C99 6.3.1.3).' For conversion to a type of width N, the value is reduced modulo 2^N to be within range of the type; no signal is raised. If this is ever to change, I'm sure you will hear about it. Paranoid users can check the manual at every compiler release. Segher