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/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
