From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2161 invoked by alias); 1 Jul 2005 01:35:32 -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 2109 invoked by uid 22791); 1 Jul 2005 01:35:24 -0000 Received: from rwcrmhc14.comcast.net (HELO rwcrmhc12.comcast.net) (216.148.227.89) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 01 Jul 2005 01:35:24 +0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (rwcrmhc14) with SMTP id <2005070101352101400o48qee>; Fri, 1 Jul 2005 01:35:21 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 01 Jul 2005 01:35:00 -0000 Subject: Re: Should GCC publish a general rule/warning due to it's default presumption of undefined signed integer overflow semantics? From: Paul Schlie To: Message-ID: In-Reply-To: <20050630232531.GA11010@synopsys.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-07/txt/msg00009.txt.bz2 > Joe Buck > Undefined behavior doesn't mean that we should attempt to arbitrarily > punish those who cross the line; that's why I don't think forcing integer > overflows to trap (at least by default) is a good idea. In many cases, > "assume no overflow, but don't trap" can produce a better result than > "assume wrap" does, as in the example I gave before. My primary concern is about predictability, and could live with undefined integer overflow if it were likely reasonably possible to verify that in the general case an overflow would not occur, as otherwise an undefined behavior may result. (which I can't believe is acceptable to anyone). Although I recognize and accept that most trivial uses of signed arithmetic can likely be verified as being constrained or not; it seems pretty clear to me that it's very difficult and often strictly impossible in the general case to do so; implying that signed integer arithmetic needs to be avoided in the general case by either specifying signed integers as being unsigned and convert them as required post-fact (which may also be undefined), and/or utilize floats if one wants to produce a program which has a reasonable chance of predictable behavior. (My question was an honest one, although candidly somewhat pointed; as prior to recent discussions it wasn't clear to me how potentially serious an issue this was; so thought being forewarned was better than being surprised by unexpected behaviors which may only express themselves in subtle non-obvious circumstances.)