Path: csiph.com!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: Mon, 11 Oct 2021 18:33:24 -0700 Organization: None to speak of Lines: 61 Message-ID: <87bl3v58nv.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> <87fst75p15.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="a7f976f3a6ead8804598b0f152cb349e"; logging-data="31732"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/7CSxR8Zo3rUtLsrRxIT0Q" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:nrEGWaPphH/jpFrSSF3xKJPTyIk= sha1:b659TXDgCXxHzoCY0D7SalKPwyg= Xref: csiph.com comp.std.c:6353 James Kuyper writes: > On 10/11/21 3:39 PM, Keith Thompson wrote: >> James Kuyper writes: > ... >>> "For decimal floating constants, and also for hexadecimal floating >>> constants when FLT_RADIX is not a power of 2, the result 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. >>> For hexadecimal floating constants when FLT_RADIX is a power of 2, the >>> result is correctly rounded." (6.4.4.2p3) >>> >>> In the case of overflow, for a type that cannot represent infinity, >>> there is only one "nearest representable value", which is DBL_MAX. >> >> But does that apply when a constraint is violated? >> >> 6.4.4p2, a constraint, says: >> >> Each constant shall have a type and the value of a constant shall be >> in the range of representable values for its type. >> >> A "constraint", aside from triggering a required diagnostic, is a >> "restriction, either syntactic or semantic, by which the exposition of >> language elements is to be interpreted", which is IMHO a bit vague. > > I can agree with the "a bit vague" description. I have previously said > "I've never understood what it is that the part of that definition after > the second comma was intended to convey." > > "If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a > constraint or runtime-constraint is violated, the behavior is undefined. > Undefined behavior is otherwise indicated in this International Standard > by the words ‘‘undefined behavior’’ or by the omission of any explicit > definition of behavior." (4p2) > > There's no mention in there of a constraint violation automatically > having undefined behavior. Most constraint violations do qualify as > undefined behavior due to the "omission of any explicit definition of > behavior" when the constraint is violated. But this isn't an example: > 6.4.4.2p3 provide a perfectly applicable definition for the behavior. I don't disagree. On the other hand, one possible interpretation of the phrase "a restriction ... by which the exposition of language elements is to be interpreted" could be that if the constraint is violated, there is no meaningful interpretation. Or to put it another way, that the semantic description applies only if all constraints are satisfied. I've searched for the word "constraint" in the C89 and C99 Rationale documents. They were not helpful. I am admittedly trying to read into the standard what I think it *should* say. A rule that constraint violations cause undefined behavior would, if nothing else, make the standard a bit simpler. -- 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 */