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 11:55:53 -0800 Organization: A noiseless patient Spider Lines: 95 Message-ID: <86sfu4y4om.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="b777881512c6754df6234a0926bb3175"; logging-data="24968"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ZQ5/Y+P3+Zjq2X8uQX5AsGBq02TLnqmg=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:Nvpac06H2ZmBmJjPSU2nH5b12ys= sha1:PRjQDk+V82Hr7l6iOFRC4nd0Cds= Xref: csiph.com comp.std.c:6406 Keith Thompson writes: > James Kuyper writes: > >> On 10/9/21 4:17 PM, Vincent Lefevre wrote: >> >>> In article <86wnmoov7c.fsf@linuxsc.com>, >>> Tim Rentsch wrote: >>> >>>> What occurs is defined behavior and (for implementations that do >>>> not have the needed value for infinity) violates a constraint. A >>>> diagnostic must be produced. >>> >>> If this is defined behavior, where is the result of an overflow >>> defined by the standard? (I can see only 7.12.1p5, but this is >>> for math functions; here, this is a constant that overflows.) >> >> "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", Note that the C standard uses the word "constraint" in at least two different senses. One is the sense of the definition given above. Another is the sense of any stated restriction in a 'Constraints' section (and nothing else). AFAICT (I have not tried to do a thorough search) the second sense never includes a syntactic restriction. > which is IMHO a bit vague. Certainly it is at least ambiguous and subjective. > My mental model is that if a program violates a constraint and the > implementation still accepts it (i.e., the required diagnostic is a > non-fatal warning) the program's behavior is undefined -- but the > standard doesn't say that. Of course if the implementation rejects > the program, it has no behavior. This paragraph uses the word "behavior" in two different senses. The C standard uses "behavior" to mean behavior in the abstract machine, or sometimes to mean a description of behavior in the abstract machine. In this sense the program has behavior whether it is rejected or not: if it has defined behavior, then that is the behavior, and if it has undefined behavior then the behavior is "undefined behavior". The sentence "if the implementation rejects the program, it has no behavior" uses the word behavior in the sense of "run-time behavior", which is a different sense than how "behavior" is used in the C standard. A C program has behavior, in the sense that the C standard uses the term, whether it is accepted or not, or even whether it is compiled or not. > For what it's worth, given this: > > double too_big = 1e1000; > > gcc, clang, and tcc all print a warning and set too_big to infinity. > That's obviously valid if the behavior is undefined. I think it's > also valid if the behavior is defined; the nearest representable > value is DBL_MAX, and the larger representable value immediately > adjacent to DBL_MAX is infinity. Since the implementations listed all have infinities, the value of the constant is in the range of representable values for its type, so no constraint is violated, and the behavior is always defined. > It doesn't seem to me to be particularly useful to say that a > program can be rejected, but its behavior is defined if the > implementation chooses not to reject it. Such cases occur often. Consider an implementation where SIZE_MAX is 4294967295. If translating a program that has a declaration static char blah[3221225472]; then the implementation is free to reject it, but the behavior is defined whether the implementation accepts the program or rejects it. Behavior is a property of the program, not the implementation.