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, 03 Jan 2022 14:36:08 -0800 Organization: None to speak of Lines: 36 Message-ID: <877dbg1m7b.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> <87bl3v58nv.fsf@nosuchdomain.example.com> <86o84sy4ba.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="4d837f920a8f89855f8c32a3a315cdd6"; logging-data="3238"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19m/qaPFgdfhb7hxK225YGL" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:C62J79iR9m7GOd421QHLnjWT1tE= sha1:2Gu07GqE5FI9xfAzYCZNH8EywrA= Xref: csiph.com comp.std.c:6411 Richard Damon writes: > On 1/3/22 3:03 PM, Tim Rentsch wrote: >> Keith Thompson writes: >> [ is a constraint violation always undefined behavior? ] >> >>> [...] 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. >> Note that constraint violations are not undefined behavior in a >> strict literal reading of the definition. Undefined behavior >> means there are no restrictions as to what an implemenation may >> do, but constraint violations require the implementation to >> issue at least one diagnostic, which is not the same as "no >> restrictions". > > Although, after issuing that one diagnostic, if the implementation > continues and generates an output program, and that program is run, > then its behavior is explicitly defined to be undefined behavior. Explicitly? Where does the standard say that. -- 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 */