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: Tue, 16 Nov 2021 19:00:02 -0800 Organization: None to speak of Lines: 67 Message-ID: <87pmqzv64t.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> <20211112231854$195e@zira.vinc17.org> <86v90t8l6j.fsf@linuxsc.com> <20211115233426$5e8a@zira.vinc17.org> <20211116011941$1337@zira.vinc17.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="6adbb48cfacfb1ab527767c44a65f2ee"; logging-data="24983"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+2hBx5pI0dYqlUny5uvfsV" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:JmF7C/jE+/re7G4GrXSavIU3nDI= sha1:mFfSrryL+cTj6e/OwzPsLhg3t9s= Xref: csiph.com comp.std.c:6394 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). 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. But I don't think we can just ignore it. I'd like to see a future standard settle this one way or the other. -- 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 */