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).
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.
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 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.
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.
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.
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.
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.
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. ItThen this means that the C standard defines something the user must
says that a *program* that uses the INFINITY macro violates a constraint >>> (if the implementation doesn't support infinities).
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 notYes, currently there is no way of fallback (without things like
defined for such implementations (as is done for the NAN macro), but
perhaps there was existing practice.
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:Even if FP_INFINITE could be defined conditionally, this would not
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.
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.
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.
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"?
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().
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.
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).
In article <87pmsqizrh.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
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.
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)? [...]
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.
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 <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.
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.
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.
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."
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.)
there are still potential issues. For instance, the standard does not guarantee that HUGE_VAL has the largest possible double value, and
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.
James Kuyper <jameskuyper@alumni.caltech.edu> writes:...
"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", which is IMHO a bit vague.
On 10/11/21 3:39 PM, Keith Thompson wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:...
"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", which is IMHO a bit vague.
I can agree with the "a bit vague" description. I have previously said
"I've never understood what it is that the part of that definition after
the second comma was intended to convey."
"If a rCyrCyshallrCOrCO or rCyrCyshall notrCOrCO requirement that appears outside of a
constraint or runtime-constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this International Standard
by the words rCyrCyundefined behaviorrCOrCO or by the omission of any explicit
definition of behavior." (4p2)
There's no mention in there of a constraint violation automatically
having undefined behavior. Most constraint violations do qualify as
undefined behavior due to the "omission of any explicit definition of behavior" when the constraint is violated. But this isn't an example: 6.4.4.2p3 provide a perfectly applicable definition for the behavior.
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.
In article <sk1pd2$5e3$3@dont-email.me>,...
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 10/9/21 4:17 PM, Vincent Lefevre wrote:
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.
OK, but I was asking "where is the result of an overflow defined by
the standard?" I don't see the word "overflow" in the above spec.
Note also that in case of overflow, "the nearest representable value"
is not defined.
On 10/26/21 6:01 AM, Vincent Lefevre wrote:
OK, but I was asking "where is the result of an overflow defined by
the standard?" I don't see the word "overflow" in the above spec.
Overflow occurs when a floating constant is created whose value is
greater than DBL_MAX or less than -DBL_MAX. Despite the fact that the
above description does not explicitly mention the word "overflow", it's perfectly clear what that description means when overflow occurs.
Note also that in case of overflow, "the nearest representable value"
is not defined.
No definition by the standard is needed; the conventional mathematical definitions of "nearest" are sufficient. If infinity is representable, DBL_MAX is always nearer to any finite value than infinity is.
Regardless of whether infinity is representable, any finite value
greater than DBL_MAX is closer to DBL_MAX than it is to any other representable value.
In article <sl9bqb$hf5$2@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 10/26/21 6:01 AM, Vincent Lefevre wrote:
OK, but I was asking "where is the result of an overflow defined by
the standard?" I don't see the word "overflow" in the above spec.
Overflow occurs when a floating constant is created whose value is
greater than DBL_MAX or less than -DBL_MAX. Despite the fact that the
above description does not explicitly mention the word "overflow", it's
perfectly clear what that description means when overflow occurs.
Why "perfectly clear"??? This is even inconsistent with 7.12.1p5
of N2596, which says:
A floating result overflows if the magnitude (absolute value)
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.
If you have a mathematical value (exact value) much larger than
DBL_MAX and that rounds to DBL_MAX (e.g. with round-toward-zero),
there should be an overflow, despite the fact that the FP result
is not greater than DBL_MAX (since it is equal to DBL_MAX).
Moreover, with the above definition, it is DBL_NORM_MAX that is
more likely taken into account, not DBL_MAX.
Note also that in case of overflow, "the nearest representable value"
is not defined.
No definition by the standard is needed; the conventional mathematical
definitions of "nearest" are sufficient. If infinity is representable,
DBL_MAX is always nearer to any finite value than infinity is.
Regardless of whether infinity is representable, any finite value
greater than DBL_MAX is closer to DBL_MAX than it is to any other
representable value.
The issue is that this may easily be confused with the result
obtained in the FE_TONEAREST rounding mode with the IEEE 754 rules
(where, for instance, 2*DBL_MAX rounds to +Inf, not to DBL_MAX,
despite the fact that 2*DBL_MAX is closer to DBL_MAX than to +Inf).
On 10/28/21 5:38 AM, Vincent Lefevre wrote:
In article <sl9bqb$hf5$2@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 10/26/21 6:01 AM, Vincent Lefevre wrote:
OK, but I was asking "where is the result of an overflow defined by
the standard?" I don't see the word "overflow" in the above spec.
Overflow occurs when a floating constant is created whose value is
greater than DBL_MAX or less than -DBL_MAX. Despite the fact that the
above description does not explicitly mention the word "overflow", it's
perfectly clear what that description means when overflow occurs.
Why "perfectly clear"??? This is even inconsistent with 7.12.1p5
of N2596, which says:
7.12.1p5 describes the math library, not the handling of floating point constants. While the C standard does recommended that "The
translation-time conversion of floating constants should match the execution-time conversion of character strings by library functions,
such as strtod , given matching inputs suitable for both conversions,
the same result format, and default execution-time rounding."
(6.4.4.2p11), it does not actually require such a match. Therefore, if
there is any inconsistency it would not be problematic.
A floating result overflows if the magnitude (absolute value)
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.
7.12.1p5 goes on to say that "If a floating result overflows and default rounding is in effect, then the function returns the value of the macro HUGE_VAL ...".
As cited above, the standard recommends, but does not require, the use
of default execution-time rounding mode for floating point constants. HUGE_VAL is only required to be positive (7.12p6) - it could be as small
as DBL_MIN.
Moreover, with the above definition, it is DBL_NORM_MAX that is
more likely taken into account, not DBL_MAX.
According to 5.2.4.2.2p19, DBL_MAX is the maximum representable finite floating point value, while DBL_NORM_MAX is the maximum normalized
number. 6.4.4.2p4 refers only to representable values, saying nothing
about normalization. Neither 7.12.5p1 nor 7.12p6 say anything to require
that the value be normalized. Therefore, as far as I can see, DBL_MAX is
the relevant value.
Note also that in case of overflow, "the nearest representable value"
is not defined.
No definition by the standard is needed; the conventional mathematical
definitions of "nearest" are sufficient. If infinity is representable,
DBL_MAX is always nearer to any finite value than infinity is.
Regardless of whether infinity is representable, any finite value
greater than DBL_MAX is closer to DBL_MAX than it is to any other
representable value.
The issue is that this may easily be confused with the result
obtained in the FE_TONEAREST rounding mode with the IEEE 754 rules
(where, for instance, 2*DBL_MAX rounds to +Inf, not to DBL_MAX,
despite the fact that 2*DBL_MAX is closer to DBL_MAX than to +Inf).
Yes, and DBL_MAX and +Inf are two of the three values permitted by
6.4.4.2p4, so I don't see any conflict there.
In article <slef9t$98j$2@dont-email.me>,...
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 10/28/21 5:38 AM, Vincent Lefevre wrote:
In article <sl9bqb$hf5$2@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 10/26/21 6:01 AM, Vincent Lefevre wrote:
7.12.1p5 describes the math library, not the handling of floating point
constants. While the C standard does recommended that "The
translation-time conversion of floating constants should match the
execution-time conversion of character strings by library functions,
such as strtod , given matching inputs suitable for both conversions,
the same result format, and default execution-time rounding."
(6.4.4.2p11), it does not actually require such a match. Therefore, if
there is any inconsistency it would not be problematic.
Yes, but this means that any implicit use of overflow is not
perfectly clear.
7.12.1p5 goes on to say that "If a floating result overflows and default
rounding is in effect, then the function returns the value of the macro
HUGE_VAL ...".
As cited above, the standard recommends, but does not require, the use
of default execution-time rounding mode for floating point constants.
HUGE_VAL is only required to be positive (7.12p6) - it could be as small
as DBL_MIN.
Note that C2x (in particular, the current draft N2731) requires that nextup(HUGE_VAL) be HUGE_VAL, probably assuming that HUGE_VAL is the
maximum value. I've just sent a mail to the CFP list about that.
about normalization. Neither 7.12.5p1 nor 7.12p6 say anything to require
that the value be normalized. Therefore, as far as I can see, DBL_MAX is
the relevant value.
But DBL_NORM_MAX is the relevant value for the general definition
of "overflow" (on double). So in 7.12p4, "overflows" is not used
correctly, at least not this the usual meaning.
More than that, with the IEEE 754 overflow definition, you have
numbers larger than DBL_MAX (up to those within 1 ulp) that do not
overflow.
No definition by the standard is needed; the conventional mathematical >>>> definitions of "nearest" are sufficient. If infinity is representable, >>>> DBL_MAX is always nearer to any finite value than infinity is.
Regardless of whether infinity is representable, any finite value
greater than DBL_MAX is closer to DBL_MAX than it is to any other
representable value.
The issue is that this may easily be confused with the result
obtained in the FE_TONEAREST rounding mode with the IEEE 754 rules
(where, for instance, 2*DBL_MAX rounds to +Inf, not to DBL_MAX,
despite the fact that 2*DBL_MAX is closer to DBL_MAX than to +Inf).
Yes, and DBL_MAX and +Inf are two of the three values permitted by
6.4.4.2p4, so I don't see any conflict there.
My point is that this definition of "nearest" does not match the
definition of IEEE 754's FE_TONEAREST.
... I'm not saying that there
is a conflict, just that the text is ambiguous. If one follows
the IEEE 754 definition, there are only two possible values
(DBL_MAX and +Inf, thus excluding nextdown(DBL_MAX)).
On 10/29/21 8:12 AM, Vincent Lefevre wrote:
In article <slef9t$98j$2@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
...On 10/28/21 5:38 AM, Vincent Lefevre wrote:
In article <sl9bqb$hf5$2@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 10/26/21 6:01 AM, Vincent Lefevre wrote:
7.12.1p5 describes the math library, not the handling of floating point
constants. While the C standard does recommended that "The
translation-time conversion of floating constants should match the
execution-time conversion of character strings by library functions,
such as strtod , given matching inputs suitable for both conversions,
the same result format, and default execution-time rounding."
(6.4.4.2p11), it does not actually require such a match. Therefore, if
there is any inconsistency it would not be problematic.
Yes, but this means that any implicit use of overflow is not
perfectly clear.
What is unclear about it? It very explicitly allows three different
values, deliberately failing to specify only one of them as valid, and
it is perfectly clear what those three values are.
But DBL_NORM_MAX is the relevant value for the general definition
of "overflow" (on double). So in 7.12p4, "overflows" is not used
correctly, at least not this the usual meaning.
What do you consider the "general definition of overflow"?
I would have though you were referring to 7.12.1p5, but I see no
wording there that distinguishes between normalized and unnormalized
values.
More than that, with the IEEE 754 overflow definition, you have
numbers larger than DBL_MAX (up to those within 1 ulp) that do not overflow.
I don't see how that's a problem.
...
No definition by the standard is needed; the conventional mathematical >>>> definitions of "nearest" are sufficient. If infinity is representable, >>>> DBL_MAX is always nearer to any finite value than infinity is.
Regardless of whether infinity is representable, any finite value
greater than DBL_MAX is closer to DBL_MAX than it is to any other
representable value.
The issue is that this may easily be confused with the result
obtained in the FE_TONEAREST rounding mode with the IEEE 754 rules
(where, for instance, 2*DBL_MAX rounds to +Inf, not to DBL_MAX,
despite the fact that 2*DBL_MAX is closer to DBL_MAX than to +Inf).
Yes, and DBL_MAX and +Inf are two of the three values permitted by
6.4.4.2p4, so I don't see any conflict there.
My point is that this definition of "nearest" does not match the
definition of IEEE 754's FE_TONEAREST.
FE_TONEAREST is not "IEEE 754's". It is a macro defined by the C
standard, and in the latest draft it's been changed so it now represents
IEC 60559's "roundTiesToEven" rounding attribute.
... I'm not saying that there
is a conflict, just that the text is ambiguous. If one follows
the IEEE 754 definition, there are only two possible values
(DBL_MAX and +Inf, thus excluding nextdown(DBL_MAX)).
Yes, that was deliberate - it was intended to be compatible with IEC
60559, but also to be sufficiently loose to allow use of non-IEC 60559 floating point.
In article <slingl$56v$1@dont-email.me>,...
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 10/29/21 8:12 AM, Vincent Lefevre wrote:
Yes, but this means that any implicit use of overflow is not
perfectly clear.
What is unclear about it? It very explicitly allows three different
values, deliberately failing to specify only one of them as valid, and
it is perfectly clear what those three values are.
These rules are not about overflow. They are general rules.
What is not defined is when a value overflows (there are different definitions). And what is the consequence of the overflow (at runtime,
there may be traps).
But DBL_NORM_MAX is the relevant value for the general definition
of "overflow" (on double). So in 7.12p4, "overflows" is not used
correctly, at least not this the usual meaning.
What do you consider the "general definition of overflow"?
The one given by the standard in 7.12.1p5.
I would have though you were referring to 7.12.1p5, but I see no
wording there that distinguishes between normalized and unnormalized
values.
"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."
If the exact result is above the maximum normal value, there is
likely to be an extraordinary roundoff error.
... I'm not saying that there
is a conflict, just that the text is ambiguous. If one follows
the IEEE 754 definition, there are only two possible values
(DBL_MAX and +Inf, thus excluding nextdown(DBL_MAX)).
Yes, that was deliberate - it was intended to be compatible with IEC
60559, but also to be sufficiently loose to allow use of non-IEC 60559
floating point.
But what is allowed is not clear for an IEEE 754 format (this does
not affect the INFINITY macro, but users could write exact values
larger than DBL_MAX + 1 ulp, for which nextdown(DBL_MAX) could be
unexpected as the obtained value).
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 Lefevre <vincent-news@vinc17.net> writes:
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.)
I'm wondering if you have resolved your original uncertainty
about the behavior of INFINITY in an implementation that does
not support infinities?
In article <861r3pbbwh.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Vincent Lefevre <vincent-news@vinc17.net> writes:
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.)
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.
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).
Ditto with Clang:
tst.c:1:18: error: initializer element is not a compile-time constant
static int i = 1 / 0;
~~^~~
Vincent Lefevre <vincent-news@vinc17.net> writes:
In article <861r3pbbwh.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Vincent Lefevre <vincent-news@vinc17.net> writes:
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.)
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?
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.
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.)
The semantics of floating constants specify that the value 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". Given that infinities are not
supported, that would be DBL_MAX or its predecessor. Based on that, I'd
say that:
- A diagnostic is required.
- A compiler may reject the program.
- If the compiler doesn't reject the program, the value of way_too_big
must be DBL_MAX or its predecessor. (Making it the predecessor of
DBL_MAX would be weird but conforming.)
*Except* that the definition of "constraint" is "restriction, either syntactic or semantic, by which the exposition of language elements is
to be interpreted". I find that rather vague, but it could be
interpreted to mean that if a constraint is violated, there is no valid interpretation of language elements.
In article <smgu08$3r1$1@dont-email.me>,...
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
I assume we've been talking about implementations that conform to the C
standard, right? Otherwise there's nothing meaningful that can be said.
The issue is more related to (strictly) conforming programs.
On 11/12/21 6:17 PM, Vincent Lefevre wrote:
In article <smgu08$3r1$1@dont-email.me>,...
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
I assume we've been talking about implementations that conform to the C
standard, right? Otherwise there's nothing meaningful that can be said.
The issue is more related to (strictly) conforming programs.
It can't be. Strictly conforming programs are prohibited from having
output that depends upon behavior that the standard leaves unspecified.
6.4.4.2p4 identifies what is usually three different possible values for
each floating point constant (four if the constant describes a value
exactly half-way between two consecutive representable values, but only
two if it describes a value larger than DBL_MAX or smaller than -DBL_MAX
on a platform that doesn't support infinities), and leaves it
unspecified which one of those values is chosen.
In article <86wnlg9ey7.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
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?
I think that constraints are there to define conditions under which specifications make sense. Thus, if a constraint is not satisfied,
behavior is undefined [...]
In article <smn6d8$c92$1@dont-email.me>,...
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 11/12/21 6:17 PM, Vincent Lefevre wrote:
The issue is more related to (strictly) conforming programs.
It can't be. Strictly conforming programs are prohibited from having
output that depends upon behavior that the standard leaves unspecified.
This is not how I interpret the standard.
Otherwise there would be
an obvious contradiction with note 3, which uses
#ifdef __STDC_IEC_559__
while the value of __STDC_IEC_559__ is not specified in the standard.
What matters is that the program needs to take every possibility into
account and make sure that the (visible) behavior is the same in each
case. So...
6.4.4.2p4 identifies what is usually three different possible values for
each floating point constant (four if the constant describes a value
exactly half-way between two consecutive representable values, but only
two if it describes a value larger than DBL_MAX or smaller than -DBL_MAX
on a platform that doesn't support infinities), and leaves it
unspecified which one of those values is chosen.
The program can deal with that in order to get the same behavior in
each case, so that it could be strictly conforming.
... However, if the
behavior is undefined (assumed as a consequence of the failed
constraint), there is *nothing* that one can do.
That said, since the floating-point accuracy is not specified, can be extremely low and is not even checkable by the program (so that there
is no possible fallback in case of low accuracy), there is not much
one can do with floating point.
Suppose again we have an implementation that does not support
infinities and has a range of double and long double up to about
ten to the 99999. Question one: as far as the C standard is
concerned, is the treatment of this .c file
double way_too_big = 1.e1000000;
and of this .c file
#include <math.h>
double way_too_big = INFINITY;
the same in the two cases?
Question two: does the C standard require that at least one
diagnostic be issued for each of the above .c files?
In article <86v90t8l6j.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Suppose again we have an implementation that does not support
infinities and has a range of double and long double up to about
ten to the 99999. Question one: as far as the C standard is
concerned, is the treatment of this .c file
double way_too_big = 1.e1000000;
and of this .c file
#include <math.h>
double way_too_big = INFINITY;
the same in the two cases?
IMHO, this is undefined behavior in both cases, due to the
unsatisfied constraint. So, yes.
On 11/15/21 4:18 AM, Vincent Lefevre wrote:
In article <smn6d8$c92$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
...On 11/12/21 6:17 PM, Vincent Lefevre wrote:
The issue is more related to (strictly) conforming programs.
It can't be. Strictly conforming programs are prohibited from having
output that depends upon behavior that the standard leaves unspecified.
This is not how I interpret the standard.
I don't see how there's room for interpretation: "A strictly conforming program ... shall not produce output dependent on any unspecified ... behavior, ..." (4p6).
... However, if the
behavior is undefined (assumed as a consequence of the failed
constraint), there is *nothing* that one can do.
Yes, but nowhere does the standard specify that violating a constraint
does, in itself, render the behavior undefined. Most constraint
violations do render the behavior undefined "by omission of any explicit definition of the behavior", but not this one. You might not like the definition that 6.4.4.2p4 provides, but it does provide one.
That said, since the floating-point accuracy is not specified, can be extremely low and is not even checkable by the program (so that there
is no possible fallback in case of low accuracy), there is not much
one can do with floating point.
??? You can check for __STDC_IEC_60559_BFP__; if it's defined, then
pretty much the highest possible accuracy is required.
On 11/15/21 6:39 PM, Vincent Lefevre wrote:
In article <86v90t8l6j.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Suppose again we have an implementation that does not support
infinities and has a range of double and long double up to about
ten to the 99999. Question one: as far as the C standard is
concerned, is the treatment of this .c file
double way_too_big = 1.e1000000;
and of this .c file
#include <math.h>
double way_too_big = INFINITY;
the same in the two cases?
IMHO, this is undefined behavior in both cases, due to the
unsatisfied constraint. So, yes.
So, of the three ways used by the standard to indicate that the behavior
is undefined, which one was used in this case?
"If a "shall" or "shall not" requirement that appears outside of a
constraint or runtime-constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this document by the words "undefined behavior" or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe "behavior that is undefined"." (4p2).
I would expect the implementation to reject the code, or accept it
in a way unspecified by the standard (but the implementation could
document what happens, as an extension).
I don't see how there's room for interpretation: "A strictly conforming program ... shall not produce output dependent on any unspecified ... behavior, ..." (4p6).
#ifdef __STDC_IEC_559__
while the value of __STDC_IEC_559__ is not specified in the standard.
In article <smuvs5$6qh$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 11/15/21 6:39 PM, Vincent Lefevre wrote:
In article <86v90t8l6j.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Suppose again we have an implementation that does not support
infinities and has a range of double and long double up to about
ten to the 99999. Question one: as far as the C standard is
concerned, is the treatment of this .c file
double way_too_big = 1.e1000000;
and of this .c file
#include <math.h>
double way_too_big = INFINITY;
the same in the two cases?
IMHO, this is undefined behavior in both cases, due to the
unsatisfied constraint. So, yes.
So, of the three ways used by the standard to indicate that the behavior
is undefined, which one was used in this case?
"If a "shall" or "shall not" requirement that appears outside of a
constraint or runtime-constraint is violated, the behavior is undefined.
Undefined behavior is otherwise indicated in this document by the words
"undefined behavior" or by the omission of any explicit definition of
behavior. There is no difference in emphasis among these three; they all
describe "behavior that is undefined"." (4p2).
Omission of any explicit definition of behavior.
... There is a constraint
(restriction) that is not satisfied.
... Thus the code becomes invalid and
nothing gets defined as a consequence.
I would expect the implementation to reject the code, or accept it
in a way unspecified by the standard (but the implementation could
document what happens, as an extension).
In article <smuc7i$6hq$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 11/15/21 4:18 AM, Vincent Lefevre wrote:
In article <smn6d8$c92$1@dont-email.me>,...
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 11/12/21 6:17 PM, Vincent Lefevre wrote:
This is not how I interpret the standard.The issue is more related to (strictly) conforming programs.
It can't be. Strictly conforming programs are prohibited from having
output that depends upon behavior that the standard leaves unspecified. >>>
I don't see how there's room for interpretation: "A strictly conforming
program ... shall not produce output dependent on any unspecified ...
behavior, ..." (4p6).
I'm not sure what you intended to mean, but IMHO, the "It can't be."
is wrong based on the unsatisfied constraint and definition 3.8 of "constraint" (but this should really be clarified).
That said, since the floating-point accuracy is not specified, can be
extremely low and is not even checkable by the program (so that there
is no possible fallback in case of low accuracy), there is not much
one can do with floating point.
??? You can check for __STDC_IEC_60559_BFP__; if it's defined, then
pretty much the highest possible accuracy is required.
Indeed, well, almost I think. One should also check that
FLT_EVAL_METHOD is either 0 or 1. Otherwise the accuracy
becomes unknown.
All,
I don't see how there's room for interpretation: "A strictly conforming
program ... shall not produce output dependent on any unspecified ...
behavior, ..." (4p6).
Indeed.
Now the order of evaluation of binary operators is
unspecified. But this does not mean that all programs containing
at least one binary operator is not strictly conforming.
For instance, the order of evaluation of the two
operands in the following expression-statement is unspecified.
But unless they are volatile qualified the output does
not depend on the unspecified behavior:
x+y;
But in:
a[printf("Hello")]+a[printf(" World")];
the output does depend on the order of evaluation,
and a program containing this code is not strictly conforming.
#ifdef __STDC_IEC_559__
while the value of __STDC_IEC_559__ is not specified in the standard.
The output of a strictly conforming program does not depend on the implementation used.
Since the value of __STDC_IEC_559__ depends on the implementation,
its use can produce a program that is not strictly conforming.
On 11/15/21 8:28 PM, Vincent Lefevre wrote:[...]
In article <smuvs5$6qh$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
"If a "shall" or "shall not" requirement that appears outside of a
constraint or runtime-constraint is violated, the behavior is undefined. >>> Undefined behavior is otherwise indicated in this document by the words
"undefined behavior" or by the omission of any explicit definition of
behavior. There is no difference in emphasis among these three; they all >>> describe "behavior that is undefined"." (4p2).
Omission of any explicit definition of behavior.
The fact that a constraint is violated does not erase the definition
provided by 6.4.4.2p4, or render it any less applicable.
... There is a constraint
(restriction) that is not satisfied.
Agreed.
... Thus the code becomes invalid and
nothing gets defined as a consequence.
This is, I presume, what makes you think that 6.4.4.2p4 is effectively erased?
The standard says nothing to that effect. The only meaningful thing it
says is that a diagnostic is required (5.1.1.3p1). I do not consider the standard's definition of "constraint" to be meaningful: "restriction,
either syntactic or semantic, by which the exposition of language
elements is to be interpreted" (3.8). What that sentence means,if
anything, is not at all clear, but one thing is clear - it says nothing about what should happen if the restriction is violated. 5.1.1.3p1 is
the only clause that says anything about that issue.
Note: the requirement specified in 5.1.1.3p1 would also be erased, if a constraint violation is considered to effectively erase unspecified
parts of the rest of the standard. Surely you don't claim that 3.8
specifies which parts get erased?
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.)
??? You can check for __STDC_IEC_60559_BFP__; if it's defined, then
pretty much the highest possible accuracy is required.
Indeed, well, almost I think. One should also check that
FLT_EVAL_METHOD is either 0 or 1. Otherwise the accuracy
becomes unknown.
A value of 2 tells you that the implementation will evaluate "all
operations and constants to the range and precision of the long double
type", which is pretty specific about what the accuracy is. It has
precisely the same accuracy that it would have had on an otherwise
identical implementation where FLT_EVAL_METHOD == 0, if you explicitly converted all double operands to long double, and then converted the
final result back to double. Would you consider the accuracy of such
code to be unknown?
A value of -1 leaves some uncertainty about the accuracy. However, the evaluation format is allowed to have range or precision that is greater
than that of the expression's type. The accuracy of such a type might be greater than that of the expression's type, but it's not allowed to be
worse.
The standard's definition of "constraint" is uncomfortably vague -- but
that doesn't mean I'm comfortable ignoring it.
Given the definition of a "constraint" as a "restriction, either
syntactic or semantic, by which the exposition of language elements is
to be interpreted", it seems to me to be at least plausible that when a constraint is violated, the "exposition of language elements" cannot be interpreted.
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.
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. [...]
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
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.
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",
which is IMHO a bit vague.
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.
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.
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.
[...] one possible interpretation of the phrase "a restriction
... by which the exposition of language elements is to be
interpreted" could be that if the constraint is violated, there
is no meaningful interpretation. Or to put it another way,
that the semantic description applies only if all constraints
are satisfied.
I've searched for the word "constraint" in the C89 and C99
Rationale documents. They were not helpful.
I am admittedly trying to read into the standard what I think
it *should* say. A rule that constraint violations cause
undefined behavior would, if nothing else, make the standard a
bit simpler.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Vincent Lefevre <vincent-news@vinc17.net> writes:
In article <861r3pbbwh.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Vincent Lefevre <vincent-news@vinc17.net> writes:
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.)
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.)
Clearly a compiler is allowed (but not required) to reject a program
that violates a constraint. If it does so, there is no 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.
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.)
[analysis of possible interpretations of the above code fragment]
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
On 11/15/21 8:28 PM, Vincent Lefevre wrote:
In article <smuvs5$6qh$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
[...]
"If a "shall" or "shall not" requirement that appears outside of
a constraint or runtime-constraint is violated, the behavior is
undefined. Undefined behavior is otherwise indicated in this
document by the words "undefined behavior" or by the omission of
any explicit definition of behavior. There is no difference in
emphasis among these three; they all describe "behavior that is
undefined"." (4p2).
Omission of any explicit definition of behavior.
The fact that a constraint is violated does not erase the
definition provided by 6.4.4.2p4, or render it any less applicable.
I suggest that that may be an open question.
... There is a constraint
(restriction) that is not satisfied.
Agreed.
... Thus the code becomes invalid and
nothing gets defined as a consequence.
This is, I presume, what makes you think that 6.4.4.2p4 is
effectively erased?
The standard says nothing to that effect. The only meaningful
thing it says is that a diagnostic is required (5.1.1.3p1). I do
not consider the standard's definition of "constraint" to be
meaningful: "restriction, either syntactic or semantic, by which
the exposition of language elements is to be interpreted" (3.8).
What that sentence means,if anything, is not at all clear, but one
thing is clear - it says nothing about what should happen if the
restriction is violated. 5.1.1.3p1 is the only clause that says
anything about that issue. Note: the requirement specified in
5.1.1.3p1 would also be erased, if a constraint violation is
considered to effectively erase unspecified parts of the rest of
the standard. Surely you don't claim that 3.8 specifies which
parts get erased?
The standard's definition of "constraint" is uncomfortably vague
-- but that doesn't mean I'm comfortable ignoring it.
Given the definition of a "constraint" as a "restriction, either
syntactic or semantic, by which the exposition of language
elements is to be interpreted", it seems to me to be at least
plausible that when a constraint is violated, the "exposition of
language elements" cannot be interpreted.
The implication would be that any program that violates a constraint
has undefined behavior (assuming it survives translation). And yes,
I'm proposing that violating any single constraint makes most of the
rest of the standard moot.
I'm not saying that this is the only way to interpret that wording.
It's vague enough to permit a number of reasonable readings. [...]
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[ is a constraint violation always undefined behavior? ]
[...] one possible interpretation of the phrase "a restriction
... by which the exposition of language elements is to be
interpreted" could be that if the constraint is violated, there
is no meaningful interpretation. Or to put it another way,
that the semantic description applies only if all constraints
are satisfied.
I've searched for the word "constraint" in the C89 and C99
Rationale documents. They were not helpful.
I am admittedly trying to read into the standard what I think
it *should* say. A rule that constraint violations cause
undefined behavior would, if nothing else, make the standard a
bit simpler.
Note that constraint violations are not undefined behavior in a
strict literal reading of the definition. Undefined behavior
means there are no restrictions as to what an implemenation may
do, but constraint violations require the implementation to
issue at least one diagnostic, which is not the same as "no
restrictions".
On 1/3/22 3:03 PM, Tim Rentsch wrote:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[ is a constraint violation always undefined behavior? ]
[...] one possible interpretation of the phrase "a restrictionNote that constraint violations are not undefined behavior in a
... by which the exposition of language elements is to be
interpreted" could be that if the constraint is violated, there
is no meaningful interpretation. Or to put it another way,
that the semantic description applies only if all constraints
are satisfied.
I've searched for the word "constraint" in the C89 and C99
Rationale documents. They were not helpful.
I am admittedly trying to read into the standard what I think
it *should* say. A rule that constraint violations cause
undefined behavior would, if nothing else, make the standard a
bit simpler.
strict literal reading of the definition. Undefined behavior
means there are no restrictions as to what an implemenation may
do, but constraint violations require the implementation to
issue at least one diagnostic, which is not the same as "no
restrictions".
Although, after issuing that one diagnostic, if the implementation
continues and generates an output program, and that program is run,
then its behavior is explicitly defined to be undefined behavior.
Keith Thompson <Keith.S.T...@gmail.com> writes:...
James Kuyper <james...@alumni.caltech.edu> writes:
...The standard says nothing to that effect. The only meaningful
thing it says is that a diagnostic is required (5.1.1.3p1). I do
not consider the standard's definition of "constraint" to be
meaningful: "restriction, either syntactic or semantic, by which
the exposition of language elements is to be interpreted" (3.8).
...The standard's definition of "constraint" is uncomfortably vague
-- but that doesn't mean I'm comfortable ignoring it.
Given the definition of a "constraint" as a "restriction, either
syntactic or semantic, by which the exposition of language
elements is to be interpreted", it seems to me to be at least
plausible that when a constraint is violated, the "exposition of
language elements" cannot be interpreted.
I'm not saying that this is the only way to interpret that wording.
It's vague enough to permit a number of reasonable readings. [...]
So you're saying that the meaning of the definition of constraint
is to some extent subjective, ie, reader dependent?
On 1/3/22 3:03 PM, Tim Rentsch wrote:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[ is a constraint violation always undefined behavior? ]
[...] one possible interpretation of the phrase "a restriction
... by which the exposition of language elements is to be
interpreted" could be that if the constraint is violated, there
is no meaningful interpretation. Or to put it another way,
that the semantic description applies only if all constraints
are satisfied.
I've searched for the word "constraint" in the C89 and C99
Rationale documents. They were not helpful.
I am admittedly trying to read into the standard what I think
it *should* say. A rule that constraint violations cause
undefined behavior would, if nothing else, make the standard a
bit simpler.
Note that constraint violations are not undefined behavior in a
strict literal reading of the definition. Undefined behavior
means there are no restrictions as to what an implemenation may
do, but constraint violations require the implementation to
issue at least one diagnostic, which is not the same as "no
restrictions".
Although, after issuing that one diagnostic, if the implementation
continues and generates an output program, and that program is run, then
its behavior is explicitly defined to be undefined behavior.
On Monday, January 3, 2022 at 3:56:22 PM UTC-5, Tim Rentsch wrote:
Keith Thompson <Keith.S.T...@gmail.com> writes:
James Kuyper <james...@alumni.caltech.edu> writes:
...
The standard says nothing to that effect. The only meaningful
thing it says is that a diagnostic is required (5.1.1.3p1). I do
not consider the standard's definition of "constraint" to be
meaningful: "restriction, either syntactic or semantic, by which
the exposition of language elements is to be interpreted" (3.8).
...
The standard's definition of "constraint" is uncomfortably vague
-- but that doesn't mean I'm comfortable ignoring it.
Given the definition of a "constraint" as a "restriction, either
syntactic or semantic, by which the exposition of language
elements is to be interpreted", it seems to me to be at least
plausible that when a constraint is violated, the "exposition of
language elements" cannot be interpreted.
...
I'm not saying that this is the only way to interpret that wording.
It's vague enough to permit a number of reasonable readings. [...]
So you're saying that the meaning of the definition of constraint
is to some extent subjective, ie, reader dependent?
As I said above, it seems to me to be so poorly worded that it's not
clear to me that it has any meaning, much less one that is subjective.
Since other people disagree with me on that point, there would
appear to be some subjectivity at play in that judgment, but after
reading their arguments, I remain at a loss as to how they can
interpret that phrase as being meaningful.
On 1/3/22 3:03 PM, Tim Rentsch wrote:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[ is a constraint violation always undefined behavior? ]
[...] one possible interpretation of the phrase "a restriction
... by which the exposition of language elements is to be
interpreted" could be that if the constraint is violated, there
is no meaningful interpretation. Or to put it another way,
that the semantic description applies only if all constraints
are satisfied.
I've searched for the word "constraint" in the C89 and C99
Rationale documents. They were not helpful.
I am admittedly trying to read into the standard what I think
it *should* say. A rule that constraint violations cause
undefined behavior would, if nothing else, make the standard a
bit simpler.
Note that constraint violations are not undefined behavior in a
strict literal reading of the definition. Undefined behavior
means there are no restrictions as to what an implemenation may
do, but constraint violations require the implementation to
issue at least one diagnostic, which is not the same as "no
restrictions".
Although, after issuing that one diagnostic, if the implementation
continues and generates an output program, and that program is run,
then its behavior is explicitly defined to be undefined behavior.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 00:50:41 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
10 files (20,373K bytes) |
| Messages: | 264,186 |