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, 17 Jan 2022 10:09:08 -0800 Organization: A noiseless patient Spider Lines: 38 Message-ID: <86mtjus08r.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> <87fst75p15.fsf@nosuchdomain.example.com> <87bl3v58nv.fsf@nosuchdomain.example.com> <86o84sy4ba.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="15598caebf32ebbe97649a2f881af1fe"; logging-data="17642"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19QT2teflsQGLSqDGV6Rx/C5+w5TMdOUas=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:KYG6hMes8MUWeGw0akugoRsjRV8= sha1:t5DCQ8hsG/WXnPCixRjLhGceS+k= Xref: csiph.com comp.std.c:6425 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. I don't think so. It may be the case that the C standard is meant to imply that a constraint violation will necessarily also result in undefined behavior, but AFAICT there is no explicit statement to that effect.