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).

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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.

Right. But there is footnote that clarifies matters:

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

so any program using INFINITY has undefined behaviour because the intent
is to violate 6.4.4. I agree that there should be a better way to
specify it, but expanding to a constant that violates the constraints on
such constants is clumsy but reasonably clear.

--
Ben.

In article <87pmsqizrh.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> 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.

Yes, but the issue here is that the standard mandates the implementation
to violate a constraint, which is rather different from the case where a
user writes buggy code.

> 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.

I think the consequence is more than a diagnostic (which may yield a
compilation failure in practice, BTW): AFAIK, the standard does not
give a particular definition for "overflows at translation time",
which would make it undefined behavior as usual for overflows.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Vincent Lefevre <vincent-news@vinc17.net> writes:
> In article <87pmsqizrh.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> 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.
>
> Yes, but the issue here is that the standard mandates the implementation
> to violate a constraint, which is rather different from the case where a
> user writes buggy code.

No, it doesn't force the implementation to violate a constraint. It
says that a *program* that uses the INFINITY macro violates a constraint
(if the implementation doesn't support infinities).

Constraints apply to programs, not to implementations.

It means that if a program assumes that INFINITY is meaningful, and it's
compiled for a target system where it isn't, a diagnostic is guaranteed.
And again, it might have made more sense to say that INFINITY is not
defined for such implementations (as is done for the NAN macro), but
perhaps there was existing practice.

Here's what the C99 Rationale says:

What is INFINITY on machines that do not support infinity? It should
be defined along the lines of: #define INFINITY 9e99999f, where
there are enough 9s in the exponent so that the value is too large
to represent as a float, hence, violates the constraint of 6.4.4
Constants. In addition, the number classification macro FP_INFINITE
should not be defined. That allows an application to test for the
existance of FP_INFINITE as a safe way to determine if infinity is
supported; this is the feature test macro for support for infinity.

The problem with this is that the standard itself doesn't say that
FP_INFINITE is defined conditionally.

>> 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.
>
> I think the consequence is more than a diagnostic (which may yield a
> compilation failure in practice, BTW): AFAIK, the standard does not
> give a particular definition for "overflows at translation time",
> which would make it undefined behavior as usual for overflows.

The meaning seems clear enough to me. It's a floating constant whose
mathematical value is outside the range of float, such as 9e99999f.
And yes, evaluating it (if the mandatory diagnostic does not cause
compilation to fail) causes undefined behavior. I think the intent is
that a portable program should check whether infinities are supported
before trying to evaluate INFINITY, but that intent is not well
reflected in the standard.

I don't think I have access to an implementation that doesn't support
infinities, so I don't know how this is handled in practice. Given the
near universal adoption of IEEE floating-point, it's probably reasonably
safe to assume that infinities are supported unless your program needs
to be painfully portable.

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

In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> No, it doesn't force the implementation to violate a constraint. It
> says that a *program* that uses the INFINITY macro violates a constraint
> (if the implementation doesn't support infinities).

Then this means that the C standard defines something the user must
not use (except when __STDC_IEC_559__ is defined, as in this case,
INFINITY is guaranteed to expand to the true infinity).

> Constraints apply to programs, not to implementations.

This is related, as programs will be transformed by an implementation.

> It means that if a program assumes that INFINITY is meaningful, and it's
> compiled for a target system where it isn't, a diagnostic is guaranteed.
> And again, it might have made more sense to say that INFINITY is not
> defined for such implementations (as is done for the NAN macro), but
> perhaps there was existing practice.

Yes, currently there is no way of fallback (without things like
autoconf tests).

Shouldn't the standard by changed to make INFINITY conditionally
defined (if not required to expand to a true infinity)?
This should not break existing programs.

> Here's what the C99 Rationale says:

> What is INFINITY on machines that do not support infinity? It should
> be defined along the lines of: #define INFINITY 9e99999f, where
> there are enough 9s in the exponent so that the value is too large
> to represent as a float, hence, violates the constraint of 6.4.4
> Constants. In addition, the number classification macro FP_INFINITE
> should not be defined. That allows an application to test for the
> existance of FP_INFINITE as a safe way to determine if infinity is
> supported; this is the feature test macro for support for infinity.

> The problem with this is that the standard itself doesn't say that
> FP_INFINITE is defined conditionally.

Even if FP_INFINITE could be defined conditionally, this would not
imply that INFINITY is usable, since for instance, long double may
have an infinity but not float.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Vincent Lefevre <vincent-news@vinc17.net> writes:
> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
[...]
> Shouldn't the standard by changed to make INFINITY conditionally
> defined (if not required to expand to a true infinity)?
> This should not break existing programs.

I agree. NAN is conditionally defined "if and only if the
implementation supports quiet NaNs for the float type". I have no
idea why the same wasn't done for INFINITY -- unless, as I mentioned
upthread, there was existing practice. INFINITY was introduced
in C99. Perhaps there were pre-C99 implementations that defined
INFINITY as an extension in the way that's now specified in the
standard. That's just speculation, and I still think making it
conditional would have made more sense.

[...]

> Even if FP_INFINITE could be defined conditionally, this would not
> imply that INFINITY is usable, since for instance, long double may
> have an infinity but not float.

The standard only defines INFINITY and NAN for type float. I think the
implication is that it assumes either all floating types have NaNs
and/or infinities, or none do. That might be a valid assumption. (The
Alpha supports both VAX and IEEE floating-point, and I don't think VAX
FP supports infinities or NaNs, but I don't think an implementation
would use, for example, VAX FP for float and IEEE for double.)

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

On 2021-10-01 11:05, Vincent Lefevre wrote:
> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> No, it doesn't force the implementation to violate a constraint. It
>> says that a *program* that uses the INFINITY macro violates a constraint
>> (if the implementation doesn't support infinities).
>
> Then this means that the C standard defines something the user must
> not use (except when __STDC_IEC_559__ is defined, as in this case,
> INFINITY is guaranteed to expand to the true infinity).
>
>> Constraints apply to programs, not to implementations.
>
> This is related, as programs will be transformed by an implementation.
>
>> It means that if a program assumes that INFINITY is meaningful, and it's
>> compiled for a target system where it isn't, a diagnostic is guaranteed.
>> And again, it might have made more sense to say that INFINITY is not
>> defined for such implementations (as is done for the NAN macro), but
>> perhaps there was existing practice.
>
> Yes, currently there is no way of fallback (without things like
> autoconf tests).
>
> Shouldn't the standard by changed to make INFINITY conditionally
> defined (if not required to expand to a true infinity)?
> This should not break existing programs.

The fallback is to test for defined(FP_INFINITE), see below.

>
>> Here's what the C99 Rationale says:
>
>> What is INFINITY on machines that do not support infinity? It should
>> be defined along the lines of: #define INFINITY 9e99999f, where
>> there are enough 9s in the exponent so that the value is too large
>> to represent as a float, hence, violates the constraint of 6.4.4
>> Constants. In addition, the number classification macro FP_INFINITE
>> should not be defined. That allows an application to test for the
>> existance of FP_INFINITE as a safe way to determine if infinity is
>> supported; this is the feature test macro for support for infinity.
>
>> The problem with this is that the standard itself doesn't say that
>> FP_INFINITE is defined conditionally.
>
> Even if FP_INFINITE could be defined conditionally, this would not
> imply that INFINITY is usable, since for instance, long double may
> have an infinity but not float.
>

I don't know if there is a set of similar macros for double and long
double types buried somewhere in the standard.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Jakob Bohm <jb-usenet@wisemo.com.invalid> writes:
> On 2021-10-01 11:05, Vincent Lefevre wrote:
>> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>> No, it doesn't force the implementation to violate a constraint. It
>>> says that a *program* that uses the INFINITY macro violates a constraint
>>> (if the implementation doesn't support infinities).
>> Then this means that the C standard defines something the user must
>> not use (except when __STDC_IEC_559__ is defined, as in this case,
>> INFINITY is guaranteed to expand to the true infinity).
>>
>>> Constraints apply to programs, not to implementations.
>> This is related, as programs will be transformed by an
>> implementation.
>>
>>> It means that if a program assumes that INFINITY is meaningful, and it's
>>> compiled for a target system where it isn't, a diagnostic is guaranteed.
>>> And again, it might have made more sense to say that INFINITY is not
>>> defined for such implementations (as is done for the NAN macro), but
>>> perhaps there was existing practice.
>> Yes, currently there is no way of fallback (without things like
>> autoconf tests).
>> Shouldn't the standard by changed to make INFINITY conditionally
>> defined (if not required to expand to a true infinity)?
>> This should not break existing programs.
>
> The fallback is to test for defined(FP_INFINITE), see below.
>
>>
>>> Here's what the C99 Rationale says:
>>
>>> What is INFINITY on machines that do not support infinity? It should
>>> be defined along the lines of: #define INFINITY 9e99999f, where
>>> there are enough 9s in the exponent so that the value is too large
>>> to represent as a float, hence, violates the constraint of 6.4.4
>>> Constants. In addition, the number classification macro FP_INFINITE
>>> should not be defined. That allows an application to test for the
>>> existance of FP_INFINITE as a safe way to determine if infinity is
>>> supported; this is the feature test macro for support for infinity.
>>
>>> The problem with this is that the standard itself doesn't say that
>>> FP_INFINITE is defined conditionally.
>> Even if FP_INFINITE could be defined conditionally, this would not
>> imply that INFINITY is usable, since for instance, long double may
>> have an infinity but not float.
>>
>
> I don't know if there is a set of similar macros for double and long
> double types buried somewhere in the standard.

The INFINITY and NAN macros are defined only for float. I think the
assumption is that either all floating-point types support infinities,
or none do, and likewise for NaNs. On the other hand, fpclassify() is a
macro that can be applied to an expression of any floating-point type.

The problem, as I said, is that the standard doesn't say that
FP_INFINITE is conditionally defined. Since they're specified in the
same section that explicitly says that NAN is conditionally defined, I
think the only reasonable reading of the standard's wording is that
FP_INFINITE is defined whether infinities are supported or not.
If they're not, it just means that fpclassify() will never return
FP_INFINITE and isinf() always returns 0.

The author(s) of the Rationale obviously *thought* that FP_INFINITE is
conditionally defined. They were mistaken. The Rationale itself makes
it clear that the Standard, not the Rationale, is what defines the
language.

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

In article <877dewimc9.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> Vincent Lefevre <vincent-news@vinc17.net> writes:
> > In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
> > Even if FP_INFINITE could be defined conditionally, this would not
> > imply that INFINITY is usable, since for instance, long double may
> > have an infinity but not float.

> The standard only defines INFINITY and NAN for type float. I think the
> implication is that it assumes either all floating types have NaNs
> and/or infinities, or none do. That might be a valid assumption.

But the standard doesn't say that explicitly. It even just says
"if and only if the implementation supports quiet NaNs for the
float type". If the intent were to have NaN support for all the
FP types or none, why doesn't it say "... for the floating types"
instead of "... for the float type"?

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Vincent Lefevre <vincent-news@vinc17.net> writes:
> In article <877dewimc9.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>> > In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
>> > Even if FP_INFINITE could be defined conditionally, this would not
>> > imply that INFINITY is usable, since for instance, long double may
>> > have an infinity but not float.
>
>> The standard only defines INFINITY and NAN for type float. I think the
>> implication is that it assumes either all floating types have NaNs
>> and/or infinities, or none do. That might be a valid assumption.
>
> But the standard doesn't say that explicitly. It even just says
> "if and only if the implementation supports quiet NaNs for the
> float type". If the intent were to have NaN support for all the
> FP types or none, why doesn't it say "... for the floating types"
> instead of "... for the float type"?

Since the NAN macro is of type float (if it's define), it only makes
sense to define it that way. Presumably if an implementation had
NaN for float but not for double, it would define NAN.

IMHO it would have been better if the assumption that all floating
types behave similarly had been stated explicitly, and perhaps if there
were three NAN macros for the three floating-point types.

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

Keith Thompson wrote:

> Presumably if an implementation had
> NaN for float but not for double, it would define NAN.
>
> IMHO it would have been better if the assumption that all floating
> types behave similarly had been stated explicitly, and perhaps if there
> were three NAN macros for the three floating-point types.

NaN support for each floating type can be queried, and a NaN
obtained if supported, by calling nanf(), nan(), and nanl().

--
Geoff Clare <netnews@gclare.org.uk>

In article <ieut2i-07m.ln1@ID-313840.user.individual.net>,
Geoff Clare <geoff@clare.see-my-signature.invalid> wrote:

> NaN support for each floating type can be queried, and a NaN
> obtained if supported, by calling nanf(), nan(), and nanl().

But they are not required to be constant expressions, while
the NAN macro expands to a constant expression.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Vincent Lefevre <vincent-news@vinc17.net> writes:
>
>> In article <877dewimc9.fsf@nosuchdomain.example.com>,
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>>>
>>>> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
>>>> Even if FP_INFINITE could be defined conditionally, this would
>>>> not imply that INFINITY is usable, since for instance, long
>>>> double may have an infinity but not float.
>>>
>>> The standard only defines INFINITY and NAN for type float. I
>>> think the implication is that it assumes either all floating types
>>> have NaNs and/or infinities, or none do. That might be a valid
>>> assumption.
>>
>> But the standard doesn't say that explicitly. It even just says
>> "if and only if the implementation supports quiet NaNs for the
>> float type". If the intent were to have NaN support for all the
>> FP types or none, why doesn't it say "... for the floating types"
>> instead of "... for the float type"?
>
> Since the NAN macro is of type float (if it's define), it only makes
> sense to define it that way. Presumably if an implementation had
> NaN for float but not for double, it would define NAN.

If float has a NaN then so do double and long double, because of
6.2.5 paragraph 10. Similarly for infinity (or infinities).

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>>> In article <877dewimc9.fsf@nosuchdomain.example.com>,
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>>>>
>>>>> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
>>>>> Even if FP_INFINITE could be defined conditionally, this would
>>>>> not imply that INFINITY is usable, since for instance, long
>>>>> double may have an infinity but not float.
>>>>
>>>> The standard only defines INFINITY and NAN for type float. I
>>>> think the implication is that it assumes either all floating types
>>>> have NaNs and/or infinities, or none do. That might be a valid
>>>> assumption.
>>>
>>> But the standard doesn't say that explicitly. It even just says
>>> "if and only if the implementation supports quiet NaNs for the
>>> float type". If the intent were to have NaN support for all the
>>> FP types or none, why doesn't it say "... for the floating types"
>>> instead of "... for the float type"?
>>
>> Since the NAN macro is of type float (if it's define), it only makes
>> sense to define it that way. Presumably if an implementation had
>> NaN for float but not for double, it would define NAN.
>
> If float has a NaN then so do double and long double, because of
> 6.2.5 paragraph 10. Similarly for infinity (or infinities).

Agreed. 6.2.5p10 says:

There are three real floating types, designated as float, double,
and long double. The set of values of the type float is a subset of
the set of values of the type double; the set of values of the type
double is a subset of the set of values of the type long double.

(No need to make everyone look it up.)

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

Vincent Lefevre <vincent-news@vinc17.net> writes:

> In article <87pmsqizrh.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

[.. use of the INFINITY macro in an implementation that does not
have a float value for infinity..]

>> 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.
>
> I think the consequence is more than a diagnostic (which may yield
> a compilation failure in practice, BTW): AFAIK, the standard does
> not give a particular definition for "overflows at translation
> time", which would make it undefined behavior as usual for
> overflows.

The compound phrase does not need defining because its relevant
constituent elements are defined in the C standard. The word
"overflows" is defined for floating point types in 7.12.1
paragraph 5

A floating result overflows if the magnitude of the
mathematical result is finite but so large that the
mathematical result cannot be represented without
extraordinary roundoff error in an object of the specified
type. [...]

The word "translation" is defined in detail in section 5.1.1.
The compound phrase "overflows at translation time" is simply a
combination of these defined terms under normal rules of English
usage.

Moreover, the C standard is quite clear that violating a
constraint must evoke a diagnostic even if there is also
undefined behavior. Section 5.1.1.3 paragraph 1 says this:

A conforming implementation shall produce at least one
diagnostic message (identified in an implementation-defined
manner) if a preprocessing translation unit or translation
unit contains a violation of any syntax rule or constraint,
even if the behavior is also explicitly specified as
undefined or implementation-defined. [...]

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.

Vincent Lefevre <vincent-news@vinc17.net> writes:

> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

[...]

>> It means that if a program assumes that INFINITY is meaningful, and
>> it's compiled for a target system where it isn't, a diagnostic is
>> guaranteed. And again, it might have made more sense to say that
>> INFINITY is not defined for such implementations (as is done for
>> the NAN macro), but perhaps there was existing practice.
>
> Yes, currently there is no way of fallback (without things like
> autoconf tests).
>
> Shouldn't the standard by changed to make INFINITY conditionally
> defined (if not required to expand to a true infinity)? [...]

To me it seems better for INFINITY to be defined as it is rather
than being conditionally defined. If what is needed is really an
infinite value, just write INFINITY and the code either works or
compiling it gives a diagnostic. If what is needed is just a very
large value, write HUGE_VAL (or HUGE_VALF or HUGE_VALL, depending)
and the code works whether infinite floating-point values are
supported or not. If it's important that infinite values be
supported but we don't want to risk a compilation failure, use
HUGE_VAL combined with an assertion

assert( HUGE_VAL == HUGE_VAL/2 );

Alternatively, use INFINITY only in one small .c file, and give
other sources a make dependency for a successful compilation
(with of course a -pedantic-errors option) of that .c file. I
don't see that having INFINITY be conditionally defined buys
anything, except to more or less force use of #if/#else/#endif
blocks in the preprocessor. I don't mind using the preprocessor
when there is a good reason to do so, but here I don't see one.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Vincent Lefevre <vincent-news@vinc17.net> writes:
[...]
>> Shouldn't the standard by changed to make INFINITY conditionally
>> defined (if not required to expand to a true infinity)? [...]
>
> To me it seems better for INFINITY to be defined as it is rather
> than being conditionally defined. If what is needed is really an
> infinite value, just write INFINITY and the code either works or
> compiling it gives a diagnostic. If what is needed is just a very
> large value, write HUGE_VAL (or HUGE_VALF or HUGE_VALL, depending)
> and the code works whether infinite floating-point values are
> supported or not. If it's important that infinite values be
> supported but we don't want to risk a compilation failure, use
> HUGE_VAL combined with an assertion
>
> assert( HUGE_VAL == HUGE_VAL/2 );
>
> Alternatively, use INFINITY only in one small .c file, and give
> other sources a make dependency for a successful compilation
> (with of course a -pedantic-errors option) of that .c file. I
> don't see that having INFINITY be conditionally defined buys
> anything, except to more or less force use of #if/#else/#endif
> blocks in the preprocessor. I don't mind using the preprocessor
> when there is a good reason to do so, but here I don't see one.

I don't see how that's better than conditionally defining INFINITY.

If you really need an infinite value, just write INFINITY and the code
either works or compiling it gives a *clearer* diagnostic for the
undeclared identifier.

If you need to test whether infinities are supported, #ifdef INFINITY is
a lot clearer than assert( HUGE_VAL == HUGE_VAL/2 ).

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

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>>>> In article <877dewimc9.fsf@nosuchdomain.example.com>,
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>>>>>
>>>>>> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
>>>>>> Even if FP_INFINITE could be defined conditionally, this would
>>>>>> not imply that INFINITY is usable, since for instance, long
>>>>>> double may have an infinity but not float.
>>>>>
>>>>> The standard only defines INFINITY and NAN for type float. I
>>>>> think the implication is that it assumes either all floating types
>>>>> have NaNs and/or infinities, or none do. That might be a valid
>>>>> assumption.
>>>>
>>>> But the standard doesn't say that explicitly. It even just says
>>>> "if and only if the implementation supports quiet NaNs for the
>>>> float type". If the intent were to have NaN support for all the
>>>> FP types or none, why doesn't it say "... for the floating types"
>>>> instead of "... for the float type"?
>>>
>>> Since the NAN macro is of type float (if it's define), it only makes
>>> sense to define it that way. Presumably if an implementation had
>>> NaN for float but not for double, it would define NAN.
>>
>> If float has a NaN then so do double and long double, because of
>> 6.2.5 paragraph 10. Similarly for infinity (or infinities).
>
> Agreed. 6.2.5p10 says:
>
> There are three real floating types, designated as float, double,
> and long double. The set of values of the type float is a subset of
> the set of values of the type double; the set of values of the type
> double is a subset of the set of values of the type long double.
>
> (No need to make everyone look it up.)

I just noticed that leaves open the possibility, for example, that
double supports infinity but float doesn't.

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

In article <874k9r7419.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> > Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> >>> Vincent Lefevre <vincent-news@vinc17.net> writes:
> >>>> In article <877dewimc9.fsf@nosuchdomain.example.com>,
> >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> >>>>> Vincent Lefevre <vincent-news@vinc17.net> writes:
> >>>>>
> >>>>>> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
> >>>>>> Even if FP_INFINITE could be defined conditionally, this would
> >>>>>> not imply that INFINITY is usable, since for instance, long
> >>>>>> double may have an infinity but not float.
> >>>>>
> >>>>> The standard only defines INFINITY and NAN for type float. I
> >>>>> think the implication is that it assumes either all floating types
> >>>>> have NaNs and/or infinities, or none do. That might be a valid
> >>>>> assumption.
> >>>>
> >>>> But the standard doesn't say that explicitly. It even just says
> >>>> "if and only if the implementation supports quiet NaNs for the
> >>>> float type". If the intent were to have NaN support for all the
> >>>> FP types or none, why doesn't it say "... for the floating types"
> >>>> instead of "... for the float type"?
> >>>
> >>> Since the NAN macro is of type float (if it's define), it only makes
> >>> sense to define it that way. Presumably if an implementation had
> >>> NaN for float but not for double, it would define NAN.
> >>
> >> If float has a NaN then so do double and long double, because of
> >> 6.2.5 paragraph 10. Similarly for infinity (or infinities).
> >
> > Agreed. 6.2.5p10 says:
> >
> > There are three real floating types, designated as float, double,
> > and long double. The set of values of the type float is a subset of
> > the set of values of the type double; the set of values of the type
> > double is a subset of the set of values of the type long double.
> >
> > (No need to make everyone look it up.)

> I just noticed that leaves open the possibility, for example, that
> double supports infinity but float doesn't.

This is what I had said above:

"[...] for instance, long double may have an infinity but not float."

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

In article <86sfxbpm9d.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> To me it seems better for INFINITY to be defined as it is rather
> than being conditionally defined. If what is needed is really an
> infinite value, just write INFINITY and the code either works or
> compiling it gives a diagnostic.

diagnostic and undefined behavior. So this is not better than
the case where INFINITY would be conditionally defined. At least,
with a conditionally defined macro, one can test it and have a
fallback, e.g. a more complex algorithm.

> If what is needed is just a very large value, write HUGE_VAL (or
> HUGE_VALF or HUGE_VALL, depending) and the code works whether
> infinite floating-point values are supported or not.

This will not work if the main code requires infinity with a possible
fallback. As a workaround, one could test HUGE_VAL as you said, but
there are still potential issues. For instance, the standard does not
guarantee that HUGE_VAL has the largest possible double value, and
this can break algorithms based on comparisons / sorting.

See note 232:

"HUGE_VAL, HUGE_VALF, and HUGE_VALL can be positive infinities in
an implementation that supports infinities."

with just "can be" instead of "shall be".

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

In article <86wnmoov7c.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> 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.)

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Vincent Lefevre <vincent-news@vinc17.net> writes:
> In article <874k9r7419.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> > Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> >>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>> >>>> In article <877dewimc9.fsf@nosuchdomain.example.com>,
>> >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> >>>>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>> >>>>>
>> >>>>>> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
>> >>>>>> Even if FP_INFINITE could be defined conditionally, this would
>> >>>>>> not imply that INFINITY is usable, since for instance, long
>> >>>>>> double may have an infinity but not float.
>> >>>>>
>> >>>>> The standard only defines INFINITY and NAN for type float. I
>> >>>>> think the implication is that it assumes either all floating types
>> >>>>> have NaNs and/or infinities, or none do. That might be a valid
>> >>>>> assumption.
>> >>>>
>> >>>> But the standard doesn't say that explicitly. It even just says
>> >>>> "if and only if the implementation supports quiet NaNs for the
>> >>>> float type". If the intent were to have NaN support for all the
>> >>>> FP types or none, why doesn't it say "... for the floating types"
>> >>>> instead of "... for the float type"?
>> >>>
>> >>> Since the NAN macro is of type float (if it's define), it only makes
>> >>> sense to define it that way. Presumably if an implementation had
>> >>> NaN for float but not for double, it would define NAN.
>> >>
>> >> If float has a NaN then so do double and long double, because of
>> >> 6.2.5 paragraph 10. Similarly for infinity (or infinities).
>> >
>> > Agreed. 6.2.5p10 says:
>> >
>> > There are three real floating types, designated as float, double,
>> > and long double. The set of values of the type float is a subset of
>> > the set of values of the type double; the set of values of the type
>> > double is a subset of the set of values of the type long double.
>> >
>> > (No need to make everyone look it up.)
>
>> I just noticed that leaves open the possibility, for example, that
>> double supports infinity but float doesn't.
>
> This is what I had said above:
>
> "[...] for instance, long double may have an infinity but not float."

Yes. My initial assumption was that the three floating-point types
could independently have or not have infinities. Tim cited 6.2.5p10,
which implies that if float has infinities, then the wider types do
also. (I wonder if the authors had infinities and NaNs in mind when
they wrote that, but the implication is still there.)

If long double has infinities, then float and double may or may not.
If float has infinities, then double and long double must.

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

On 10/9/21 4:17 PM, Vincent Lefevre wrote:
> In article <86wnmoov7c.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> 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.

On 10/9/21 4:05 PM, Vincent Lefevre wrote:
....
> there are still potential issues. For instance, the standard does not
> guarantee that HUGE_VAL has the largest possible double value, and

In fact, a fully conforming implementation could define it to match
DBL_MIN. I think that's a defect.