From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10832 invoked by alias); 18 Jun 2005 18:08:59 -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 10807 invoked by uid 22791); 18 Jun 2005 18:08:53 -0000 Received: from admin.voldemort.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 18 Jun 2005 18:08:53 +0000 Received: (qmail 28638 invoked from network); 18 Jun 2005 18:08:51 -0000 Received: from localhost (HELO digraph.polyomino.org.uk) (joseph@127.0.0.1) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 18 Jun 2005 18:08:51 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.51) id 1DjhkP-0006bF-9V; Sat, 18 Jun 2005 18:08:49 +0000 Date: Sat, 18 Jun 2005 18:08:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Paul Schlie cc: Dale Johannesen , Robert Dewar , Mike Stump , Andrew Pinski , GCC Development Subject: Re: basic VRP min/max range overflow question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-06/txt/msg00750.txt.bz2 On Sat, 18 Jun 2005, Paul Schlie wrote: > > You appear to have confused unspecified behavior (where the possibilities > > are bounded) and undefined behavior (where the possibilities are > > unbounded). On *undefined* behavior (such as signed integer overflow), > > *this International Standard imposes no requirements*. If a program > > execution involved undefined behavior, *there are no requirements on its > > execution, even before the undefined behavior occurs in the abstract > > machine*. > > No, the standard clearly states that it imposes no requirements on the > behavior which an implementation may choose to implement for (and limited > to) that specific undefined behavior; as regardless of that behavior, it's > resulting side effects clearly remains constrained by the rules as specified > in 5.1.2.3. > > [#1] Behavior where this International Standard provides two > or more possibilities and imposes no requirements on which > is chosen in any instance. A program that is correct in all > other aspects, operating on correct data, containing > unspecified behavior shall be a correct program and act in > accordance with subclause 5.1.2.3. 1. This section describes unspecified behavior, not undefined behavior. This discussion is about undefined behavior, not unspecified behavior. You appear to be trying deliberately to confuse the matter by misleading quotation of a section about something other than the topic (undefined behavior) under discussion. You also appear to have removed the heading "unspecified behavior" of this section which would show that your quotation is irrelevant, in order to confuse readers who don't check quotations claiming to be from the standard to see whether they are genuine and relevant. 2. No section with the wording you quote appears in the standard; you appear to be conflating two different sections, 3.4.4#1 and 4#3. 3. 3.4.4#1 had "use of an unspecified value, or other " prepended in TC2, so you are *misquoting* an *obsolete* standard version. "undefined" and "unspecified" have completely different meanings in C standard context. Until you understand this and are willing to refer only to relevant parts of the correct standard version without silently concatenating different sections and removing the section headings where they would contradict your claims, there is no point in your posting to this list or anywhere else C standards are discussed, and readers must presume that what you post claiming to be a quotation from the standard is not such a quotation or is placed in misleading context until they check the standard themselves. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ jsm@polyomino.org.uk (personal mail) joseph@codesourcery.com (CodeSourcery mail) jsm28@gcc.gnu.org (Bugzilla assignments and CCs)