Path: csiph.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!feeder1.feed.usenet.farm!feed.usenet.farm!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.std.c Subject: Re: contradiction about the INFINITY macro Date: Wed, 10 Nov 2021 15:01:46 -0800 Organization: None to speak of Lines: 90 Message-ID: <87fss3wr6t.fsf@nosuchdomain.example.com> References: <20210930012112$48d9@zira.vinc17.org> <87pmsqizrh.fsf@nosuchdomain.example.com> <20210930105413$d6e8@zira.vinc17.org> <86wnmoov7c.fsf@linuxsc.com> <20211009201151$a68b@zira.vinc17.org> <861r3pbbwh.fsf@linuxsc.com> <20211110124948$eea4@zira.vinc17.org> <86wnlg9ey7.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="640c055bf41f454a93fe46a7d3c009df"; logging-data="26187"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18x+J3wuDOLM+PmyvM6ynBw" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:wxWVXNkuZurk2xCQznLBE3zGIAw= sha1:5N+/IdQCRMckksQMgduJoMlsWPo= Xref: csiph.com comp.std.c:6377 Tim Rentsch writes: > Vincent Lefevre writes: >> In article <861r3pbbwh.fsf@linuxsc.com>, >> Tim Rentsch wrote: >>> Vincent Lefevre writes: >>>> In article <86wnmoov7c.fsf@linuxsc.com>, >>>> Tim Rentsch wrote: >>>>> What occurs is defined behavior and (for implementations that do >>>>> not have the needed value for infinity) violates a constraint. >>>>> A diagnostic must be produced. >>>> >>>> If this is defined behavior, where is the result of an overflow >>>> defined by the standard? (I can see only 7.12.1p5, but this is >>>> for math functions; here, this is a constant that overflows.) >>> >>> I'm wondering if you have resolved your original uncertainty >>> about the behavior of INFINITY in an implementation that does >>> not support infinities? >> >> I suspect that by saying "overflow", the standard actually meant that >> the result is not in the range of representable values. This is the >> only way the footnote "In this case, using INFINITY will violate the >> constraint in 6.4.4 and thus require a diagnostic." can make sense >> (the constraint in 6.4.4 is about the range, not overflow). But IMHO, >> the failing constraint makes the behavior undefined, actually makes >> the program erroneous. > > Suppose we have an implementation that does not support > infinities, a range of double and long double up to about ten to > the 99999, and ask it to translate the following .c file > > double way_too_big = 1.e1000000; > > This constant value violates the constraint in 6.4.4. Do you > think this .c file (and any program it is part of) has undefined > behavior? If so, do you think any constraint violation implies > undefined behavior, or just some of them? (Jumping in though the question was addressed to someone else.) I think it's a tricky question. I think the language would be cleaner if the standard explicitly stated that violating a constraint always results in undefined behavior -- or if it explicitly stated that it doesn't. (The former is my personal preference.) Clearly a compiler is allowed (but not required) to reject a program that violates a constraint. If it does so, there is no behavior. So the question is whether the behavior is undefined if the implementation chooses not to reject it. (I personally don't see a whole lot of value in defining the behavior of code that could have been rejected outright. I'm also not a big fan of the fact that required diagnostics don't have to be fatal, but that's not likely to change.) The semantics of floating constants specify that the value is "either the nearest representable value, or the larger or smaller representable value immediately adjacent to the nearest representable value, chosen in an implementation-defined manner". Given that infinities are not supported, that would be DBL_MAX or its predecessor. Based on that, I'd say that: - A diagnostic is required. - A compiler may reject the program. - If the compiler doesn't reject the program, the value of way_too_big must be DBL_MAX or its predecessor. (Making it the predecessor of DBL_MAX would be weird but conforming.) *Except* that the definition of "constraint" is "restriction, either syntactic or semantic, by which the exposition of language elements is to be interpreted". I find that rather vague, but it could be interpreted to mean that if a constraint is violated, there is no valid interpretation of language elements. Rejecting 1.e1000000 with a fatal diagnostic is clearly conforming. Issuing a non-fatal warning for 1.e1000000 and setting way_too_big to DBL_MAX is conforming (even if the behavior is/were undefined, that's perfectly valid). An implementation that issues a non-fatal warning for 1.e1000000 and sets way_too_big to 42.0 is arguably non-conforming, but if its implementers argue that the behavior is undefined because of their interpretation of the standard's definition of "constraint", I'd have a hard time claiming they're wrong. [...] -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */