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:48:56 -0800 Organization: A noiseless patient Spider Lines: 101 Message-ID: <86k0fgy287.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> <87fss3wr6t.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="U2FsdGVkX19/LA5tbl/AJ5nYKGlsG0s5C9Xfxjdj97Y=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:fpwtyGYpLs3VuDYz5FULX49XT7k= sha1:jnUi3JdXDrdLTuyaU+hc9jXbZKA= Xref: csiph.com comp.std.c:6408 Keith Thompson writes: > Tim Rentsch writes: > >> Vincent Lefevre writes: >> >>> In article <861r3pbbwh.fsf@linuxsc.com>, >>> Tim Rentsch wrote: >>> >>>> Vincent Lefevre writes: >>>> >>>>> 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.) >>>> >>>> I'm wondering if you have resolved your original uncertainty >>>> about the behavior of INFINITY in an implementation that does >>>> not support infinities? >>> >>> I suspect that by saying "overflow", the standard actually meant that >>> the result is not in the range of representable values. This is the >>> only way the footnote "In this case, using INFINITY will violate the >>> constraint in 6.4.4 and thus require a diagnostic." can make sense >>> (the constraint in 6.4.4 is about the range, not overflow). But IMHO, >>> the failing constraint makes the behavior undefined, actually makes >>> the program erroneous. >> >> Suppose we have an implementation that does not support >> infinities, a range of double and long double up to about ten to >> the 99999, and ask it to translate the following .c file >> >> double way_too_big = 1.e1000000; >> >> This constant value violates the constraint in 6.4.4. Do you >> think this .c file (and any program it is part of) has undefined >> behavior? If so, do you think any constraint violation implies >> undefined behavior, or just some of them? > > (Jumping in though the question was addressed to someone else.) > > I think it's a tricky question. I think the language would be > cleaner if the standard explicitly stated that violating a > constraint always results in undefined behavior -- or if it > explicitly stated that it doesn't. (The former is my personal > preference.) Here are some statements that I believe are true: 1. The C standard has no statement that says directly that constraint violations result in undefined behavior. 2. The definition of "constraint" in the C standard is ambiguous and does not have a single objective meaning. 3. There are no indications (at least none that I am aware of) in the C standard, or any other official writing of the WG14 group, of what meaning is intended by the ISO C group for the question in question. > Clearly a compiler is allowed (but not required) to reject a program > that violates a constraint. If it does so, there is no behavior. Same comment as I gave in my other recent posting - programs have behavior, in the sense used in the C standard, regardless of whether any implementation accepts or rejects them. (The behavior may be "undefined behavior".) > So the question is whether the behavior is undefined if the > implementation chooses not to reject it. (I personally don't see a > whole lot of value in defining the behavior of code that could have > been rejected outright. Again, there are lots of constructs that clearly have defined behavior, and yet implementations can choose to reject them. > I'm also not a big fan of the fact that > required diagnostics don't have to be fatal, but that's not likely > to change.) IMO this view is short sighted. Implementations are allowed to define extensions as long as they are documented and don't change the meaning of any strictly conforming program. If any required diagnostic has to be fatal, that would disallow all kinds of useful extensions. Speaking just for myself, I would like implementations to provide an option under which any required diagnostic would result in the program being rejected. But only an option, and in any case that is in the area of QOI issues, which the C standard has explicitly chosen not to address. > [analysis of possible interpretations of the above code fragment] My question was only about whether there is undefined behavior.