From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3944 invoked by alias); 20 Jun 2005 21:47:17 -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 3908 invoked by uid 22791); 20 Jun 2005 21:47:06 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 20 Jun 2005 21:47:06 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j5KLl1K7025560 for ; Mon, 20 Jun 2005 14:47:01 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Mon, 20 Jun 2005 14:45:44 -0700 Received: from [17.201.24.155] (mrs.apple.com [17.201.24.155]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id j5KLjfTL021287; Mon, 20 Jun 2005 14:45:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <078E9A0E-45B9-4CF7-B95E-9CB20A1189EC@apple.com> Cc: Dale Johannesen , Robert Dewar , Andrew Pinski , GCC Development Content-Transfer-Encoding: 7bit From: Mike Stump Subject: Re: basic VRP min/max range overflow question Date: Mon, 20 Jun 2005 21:47:00 -0000 To: Paul Schlie X-SW-Source: 2005-06/txt/msg00927.txt.bz2 General note, please, this list is for developers of gcc to develop gcc. Using it as a way to teach yourself how to read the C standard, isn't ok, please stop. On Saturday, June 18, 2005, at 07:15 AM, Paul Schlie wrote: > Maybe I didn't phrase my statement well; I think you did, you are just wrong. Please quote the sentence that says the the program behaves in accordance with 5.1.2.3, if you can find none, then, trivially, there is no such requirement. If you can find it, you can quote it. Failure to find it, means either, you didn't look hard enough, or there is none. Here, let me try again, in a slightly different way: --If a program contains no violations of the rules in this Interna- tional Standard, a conforming implementation shall, within its resource limits, accept and correctly execute2) that program. --If a program contains a violation of a rule for which no diagnostic is required, this International Standard places no requirement on implementations with respect to that program. 1.4.12 undefined behavior [defns.undefined] behavior, such as might arise upon use of an erroneous program con- struct or of erroneous data, for which the Standard imposes no requirements. Undefined behavior may also be expected when the stan- dard omits the description of any explicit definition of behavior. Read it slowly, carefully, then instead of replying, go ask 100 programmers not on this list what they think the words mean, listen to them. Come back here and summarize, if the result is different from what we represent. > I fully agree with the cited paragraph above which specifically > says a program containing unspecified behavior "shall be a > correct program and act in accordance with 5.1.2.3". Which > specifies program execution, in terms of an abstract machine model, > which correspondingly requires: I love it, you quote 5.1.2.3, but that section has no relevance to the program, if you can't find something that gives it relevance. Go back and try again. > Therefore regardless of the result of an "undefined" result/ > operation at > it's enclosing sequence point, the remaining program must continue > to abide > by the specified semantics of the language. Nope. You have failed to grasp that `can do anything' actually means can do anything. If the standard mean to say that all preceding semantics must be observable, the standard would say that, if you can find where it says that all observable semantics are required in all sequence points before the one containing the undefined behavior, then, maybe that standard doesn't say that.