Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.std.c
Subject: Re: contradiction about the INFINITY macro
Date: Wed, 29 Sep 2021 19:05:38 -0700
Organization: None to speak of
Lines: 45
Message-ID: <87pmsqizrh.fsf@nosuchdomain.example.com>
References: <20210930012112$48d9@zira.vinc17.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="4b075a85c80fa8b78011f466bfabf6da"; logging-data="15654"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18NQ+O0BrrT59uFxq7Mu0As"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:lglA4qhEpGKwSAxhS8TEpl3WWuw= sha1:tzqPzvdscMewq8P/Wv8fdGMDFu4=
Xref: csiph.com comp.std.c:6322

Vincent Lefevre <vincent-news@vinc17.net> writes:
> In ISO C99:TC3 to C17, 7.12p4:
>
>   The macro INFINITY expands to a constant expression of type float
>   representing positive or unsigned infinity, if available; else to a
>   positive constant of type float that overflows at translation time.
>
> Consider the "else" case. It is said that INFINITY expands to a
> constant and that it overflows, so that it is not in the range of
> representable values of float.
>
> But in 6.4.4p2:
>
>   Each constant shall have a type and the value of a constant shall
>   be in the range of representable values for its type.
>
> which would imply that INFINITY expands to a value in the range of
> representable values of float, contradicted by 7.12p4.
>
> Same issue in the current C2x draft N2596 (7.12p7 and 6.4.4p2).

6.4.4p2 is a constraint.  It doesn't make it impossible to write code
that violates that constraint.

If I understand correctly, it means that if an infinite value is not
available, then a program that refers to the INFINITY macro (in a
context where it's treated as a floating-point expression) violates that
constraint, resulting in a required diagnostic.

In fact I wrote the previous paragraph before I read the footnote on the
definition of INFINITY (N1570 7.12p4, footnote 229):

    In this case, using INFINITY will violate the constraint in 6.4.4
    and thus require a diagnostic.

There is no contradiction.

(I wonder if it would have been more useful to require that INFINITY not
be defined unless it can be defined as an actual infinity, but I haven't
given it a lot of thought.)

-- 
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 */