Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.std.c Subject: Re: contradiction about the INFINITY macro Date: Mon, 03 Jan 2022 12:56:19 -0800 Organization: A noiseless patient Spider Lines: 76 Message-ID: <86fsq4y1vw.fsf@linuxsc.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> <20211112231854$195e@zira.vinc17.org> <86v90t8l6j.fsf@linuxsc.com> <20211115233426$5e8a@zira.vinc17.org> <20211116011941$1337@zira.vinc17.org> <87pmqzv64t.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="b777881512c6754df6234a0926bb3175"; logging-data="17051"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/WlU9c0kV16+Ek1V/5jnhYgjwZoL6vFVI=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:SEXIm/Sx7iy42pZ4TrnU+faY6Rk= sha1:6h8++j3iMYkW42D/PTj2d34uk1w= Xref: csiph.com comp.std.c:6409 Keith Thompson writes: > James Kuyper writes: > >> On 11/15/21 8:28 PM, Vincent Lefevre wrote: >> >>> In article , >>> James Kuyper wrote: > > [...] > >>>> "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 >>>> document by the words "undefined behavior" or by the omission of >>>> any explicit definition of behavior. There is no difference in >>>> emphasis among these three; they all describe "behavior that is >>>> undefined"." (4p2). >>> >>> Omission of any explicit definition of behavior. >> >> The fact that a constraint is violated does not erase the >> definition provided by 6.4.4.2p4, or render it any less applicable. > > I suggest that that may be an open question. > >>> ... There is a constraint >>> (restriction) that is not satisfied. >> >> Agreed. >> >>> ... Thus the code becomes invalid and >>> nothing gets defined as a consequence. >> >> This is, I presume, what makes you think that 6.4.4.2p4 is >> effectively erased? >> >> The standard says nothing to that effect. The only meaningful >> thing it says is that a diagnostic is required (5.1.1.3p1). I do >> not consider the standard's definition of "constraint" to be >> meaningful: "restriction, either syntactic or semantic, by which >> the exposition of language elements is to be interpreted" (3.8). (Incidental remark: the problem is not that the definition of constraint is meaningless; the problem is that the meaning of the definition is ambiguous and subjective (but that's not the same as meaningless (or "not meaningful")).) >> What that sentence means,if anything, is not at all clear, but one >> thing is clear - it says nothing about what should happen if the >> restriction is violated. 5.1.1.3p1 is the only clause that says >> anything about that issue. Note: the requirement specified in >> 5.1.1.3p1 would also be erased, if a constraint violation is >> considered to effectively erase unspecified parts of the rest of >> the standard. Surely you don't claim that 3.8 specifies which >> parts get erased? > > The standard's definition of "constraint" is uncomfortably vague > -- but that doesn't mean I'm comfortable ignoring it. > > Given the definition of a "constraint" as a "restriction, either > syntactic or semantic, by which the exposition of language > elements is to be interpreted", it seems to me to be at least > plausible that when a constraint is violated, the "exposition of > language elements" cannot be interpreted. > > The implication would be that any program that violates a constraint > has undefined behavior (assuming it survives translation). And yes, > I'm proposing that violating any single constraint makes most of the > rest of the standard moot. > > I'm not saying that this is the only way to interpret that wording. > It's vague enough to permit a number of reasonable readings. [...] So you're saying that the meaning of the definition of constraint is to some extent subjective, ie, reader dependent?