Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: James Kuyper Newsgroups: alt.comp.lang.borland-delphi,alt.math,comp.arch,comp.graphics.algorithms,comp.lang.c Subject: Re: Infinity + Infinity (or NegInfinity - NegInfinity) Date: Wed, 12 Oct 2011 15:32:31 -0400 Organization: A noiseless patient Spider Lines: 106 Message-ID: <4E95EB4F.20903@verizon.net> References: <89f27$4e8f9f40$5419acc3$12829@cache4.tilbu1.nb.home.nl> <88cbbc8b-1fab-4dde-96b0-4dd0cd7c183d@b6g2000vbz.googlegroups.com> <4E95BBEE.3000005@verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Injection-Info: mx04.eternal-september.org; posting-host="2P71cupDoazVVolqpw1jrw"; logging-data="19423"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19gbnM6VQN/FkeqTssLd/2Kzw6P7LMc3KY=" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 In-Reply-To: Cancel-Lock: sha1:uF8l6WtIXaORU8UW7TaBjGvB37Q= Xref: x330-a1.tempe.blueboxinc.net comp.arch:4161 comp.graphics.algorithms:513 comp.lang.c:11596 On 10/12/2011 01:41 PM, nmm1@cam.ac.uk wrote: > In article <4E95BBEE.3000005@verizon.net>, > James Kuyper wrote: ... >> position, and IMO fully defensible, is that the BNF implies constraints >> on the execution order. For instance, in ((a+b) + (c+d)), the a+b can be >> executed before or after the (c+d), but both must be executed before the >> final addition can be performed, because that addition requires the >> results of those execution. > > Well, yes, but I never said it wasn't! What I said was that there > were lots of OTHER interpretations, which were ALSO defensible. I'm sure that there are alternative interpretations, many of them defensible. The relevant thing would be a defensible interpretation that differs from the one I gave in ways that would be problematic. Every problematic interpretation I could come up with was indefensible for reasons directly connected to the fact that was problematic. Could you give an example? ... >> However, for an implementation that pre-#defines __STDC_IEC_559__, it >> seems to me that the "final result" necessarily includes the values of >> testable floating point environment flags; at least, if it occurs within >> code that actual performs such tests. > > I can tell you that most of the proponents of that agree with you; > unfortunately a lot of WG14 didn't, and so it was left up in the air. An argument against that interpretation would be more relevant than an assertion that there are people who believe in the validity of that argument. >> You know this, but for the benefit of those who don't: C99 added >> , providing portable C support for such flags. > > I know damn well it didn't! It might not have done it as well as you might have liked - but it did do it. :-) ... > Secondly, the problem is NOT solely optionality (as you claimed > that I showed) ... That's the main thing I remembered you arguing; I didn't mean to imply that the arguments I remembered were the only ones you actually made - my memory's not that good. > ... - it's serious ambiguity and even inconsistency. > Here is one example of the problem. > > 5.1.2.3 Program execution footnote 11: > > ... Floating-point operations implicitly set the status flags; .... > Implementations that support such floating-point state are required > to regard changes to it as side effects .... > > 6.5 Expressions para. 5: > > If an exceptional condition occurs during the evaluation of an > expression (that is, if the result is not mathematically defined or > not in the range of representable values for its type), the behavior > is undefined. > > 7.6 Floating-point environment para. 1: > > ... A floating-point status flag is a system variable whose value > is set (but never cleared) when a floating-point exception is > raised, which occurs as a side effect of exceptional floating-point > arithmetic to provide auxiliary information. ... > > Now, 6.5 states unequivocally that exceptional conditions lead to > undefined behaviour, which is assuredly sometimes the case. But > Annex F states they are not if __STDC_IEC_559__ is defined. Why > do you claim that the latter overrides the former, and not the > former the latter? Specifications for particular cases are routinely considered to override any conflicting specification covering more the general cases; the standard would require a lot of complicated re-wording if that weren't true. #ifdef __STDC_IEC_559__ is more specific than #ifndef. > That would have been trivial to fix, What fix do you think would be needed? "An implementation that defines __STDC_IEC_559_ _ shall conform to the specifications in this annex." (F1.1). Should they add the words "even in circumstances where the rest of the standard says that the behavior is undefined."? That would seem redundant with the simple word "shall" to me. What does the "shall" mean in this context if it doesn't already imply that? 4p1: "‘‘shall’’ is to be interpreted as a requirement on an implementation or on a program;" This is clearly a requirement imposed on the implementation. 3.4.3p1: undefined behavior "behavior, ... for which this International Standard imposes no requirements." Annex F is a part of "this International Standard", is labeled as normative, and imposes requirements for the behavior when an implementation chooses to pre-#define __STDC_IEC_559__. That doesn't seem to meet the standard's definition of "undefined behavior".