From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2229 invoked by alias); 29 Jun 2005 09:04:53 -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 514 invoked by uid 22791); 29 Jun 2005 09:04:27 -0000 Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 29 Jun 2005 09:04:27 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j5T94Na6107484 for ; Wed, 29 Jun 2005 09:04:23 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5T94NIk159540 for ; Wed, 29 Jun 2005 11:04:23 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j5T94Mi3022677 for ; Wed, 29 Jun 2005 11:04:23 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j5T94MMW022672; Wed, 29 Jun 2005 11:04:22 +0200 In-Reply-To: <42C25EDF.4010700@adacore.com> Subject: Re: The utility of standard's semantics for overflow To: Robert Dewar Cc: gcc@gcc.gnu.org Message-ID: From: Michael Veksler Date: Wed, 29 Jun 2005 09:04:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-SW-Source: 2005-06/txt/msg01243.txt.bz2 Robert Dewar wrote on 29/06/2005 11:42:07: > Michael Veksler wrote: > > > If the programmer wants a robust application, > > then casting to unsigned must be present for almost any > > usage of int. > > If you have a variable in your program that is signed but must > always be in the range of int, then int is the appropriate > representation. If the pressure in a tank must be in the > range -2**31 .. +2**31-1, it does not make the application > more robust to ensure that if the pressure goes "over" the max, it > suddenly turns negative. That's likely to be just as > disastrous as any other behavior in this serious error > situation. This is right to some extent, and I referred to it in my original mail. I claim that it is easier to write a code that checks these cases after the overflow, rather than before. I also claim that checking overflows (as implied by the standard) results in almost pure unsigned arithmetic, so why do we have signed arithmetic to begin with? > > In practice of course, the pressure in this example is > likely to be in a much more constrained range, and part > of making a "robust application" will be to ensure that > the value always remains in the required range. In a more > expressive language like Ada, the corresponding type would > be declared with the appropriate range, and an exception > would be raised if the value is outside this range. But this is not what C does. In C there is an assumption "bugs like int overflow may be transformed into any other possible bug". No exception need be raised. > In practice in a critical application, you are likely to > not want any exceptions, so proving such a program exception > free is one of the tasks that faces the applications programmer > in writing a reliable program. See for example: > > http://www.praxis-cs.com/pdfs/Industrial_strength.pdf > And as it is written in section 3 "... gives compiler writers substantial freedom to re-order expressions ..." and then "A more sound approach is to design a language so that these ordering effects cannot occur". This last quote can be implemented only by moving to modulo semantics.