Path: csiph.com!news.mixmin.net!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: Wed, 10 Nov 2021 08:02:24 -0800 Organization: A noiseless patient Spider Lines: 77 Message-ID: <86wnlg9ey7.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="8c1429c1e47e3903a34e83cdcbb6a84c"; logging-data="9610"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/VWnQN3DRvZfcOKWtUZ/sdENvs+9sEH/M=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:zxBm7XLnQuSOG2Adgt7wyNFKXnY= sha1:K3eoNOg1FkfXn8ezpatJ95xyR+4= Xref: csiph.com comp.std.c:6375 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? > Similarly, on > > static int i = 1 / 0; > int main (void) > { > return 0; > } > > GCC fails to translate the program due to the failing constraint: > > tst.c:1:16: error: initializer element is not constant > 1 | static int i = 1 / 0; > | ^ > > (this is not just a diagnostic, GCC does not generate an > executable). Note that the C standard does not distinguish between "errors" and "warnings" in diagnostic messages. Either is allowed regardless of whether undefined behavior is present. > Ditto with Clang: > > tst.c:1:18: error: initializer element is not a compile-time constant > static int i = 1 / 0; > ~~^~~ The messages indicate that the failure is not about exceeding the range of a type, but rather about satisfying the constraints for constant expressions, in particular 6.6 p4, which says in part Each constant expression shall evaluate to a constant [...] The problem here is that 1/0 doesn't evaluate to anything, because division by 0 is not defined. Any question of range of representable values doesn't enter into it.