From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16151 invoked by alias); 30 Jun 2005 20:08:30 -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 15702 invoked by uid 22791); 30 Jun 2005 20:08:23 -0000 Received: from sccrmhc12.comcast.net (HELO sccrmhc12.comcast.net) (204.127.202.56) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 30 Jun 2005 20:08:23 +0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (sccrmhc12) with SMTP id <2005063020082001200jichte>; Thu, 30 Jun 2005 20:08:21 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 30 Jun 2005 20:08: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: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-06/txt/msg01325.txt.bz2 (sorry, meant additive/multiplicative inverse +/- MAX/MIN_ value; but even that's wrong, which is why it seems that leaving signed overflow as being undefined is such a bad idea, as it becomes correspondingly very difficult to even try determine if a program is warranted to have a deterministic behavior, or potentially a completely arbitrary one.) > Given that the formal implication of GCC's choice not define signed integer > overflow semantics as being other than undefined will be to guaranteed that > all programs, with reachable signed integer arithmetic operations which can > not warrant that their respective operand expressions are recursively > constrained to each others corresponding additive or multiplicative inverse, > may produce unpredictably arbitrary results and/or behavior by default; might > it be a good idea to publish a formal rule/warning, as it's a good thing to > know and not particularly obvious: > > - Signed integer types and/or arithmetic operations should not be utilized > in GCC compiled programs (or any program desired to be strictly portable, > even if it's values are known or desired to be constrained to signed > integers) unless it is provably known that the corresponding operands to > all signed arithmetic operation which may use their values directly and/or > indirectly are correspondingly recursively constrained to their respective > additive or multiplicative inverse. As GCC complied programs may produce > arbitrary results and/or behavior in such instances by default, as enabled > by the C/C++ standards. > > Or more generally as C/C++'s default integer promotion rules may convert > unsigned integer types to signed operand types if it's other operand is > signed, should the general rule be broadened to discourage the use of all > integer variable types unless all signed integer operations which may utilize > their values directly or indirectly are provably known to have > their correspondingly operands constrained to their respective additive or > multiplicative inverse value ranges? > > (or if by default it warrants otherwise, maybe that should be stated?)