Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.std.c > #6321 > unrolled thread
| Started by | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| First post | 2021-09-30 01:47 +0000 |
| Last post | 2021-09-30 03:20 +0100 |
| Articles | 20 on this page of 80 — 10 participants |
Back to article view | Back to comp.std.c
contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-09-30 01:47 +0000
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-29 19:05 -0700
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-09-30 11:24 +0000
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-30 08:38 -0700
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-01 09:05 +0000
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-01 12:20 -0700
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-04 09:26 +0000
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-04 10:34 -0700
Re: contradiction about the INFINITY macro Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2021-10-05 13:53 +0100
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-06 00:12 +0000
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-07 07:05 -0700
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-07 07:51 -0700
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-08 11:41 -0700
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-09 19:49 +0000
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-09 14:28 -0700
Re: contradiction about the INFINITY macro Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2021-10-01 22:55 +0200
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-01 14:26 -0700
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-08 08:30 -0700
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-08 11:40 -0700
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-17 21:00 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-09 20:05 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-11 12:40 -0400
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-17 21:02 -0800
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-08 00:02 -0700
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-09 20:17 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-11 12:40 -0400
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-11 12:39 -0700
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-11 21:04 -0400
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-11 18:33 -0700
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-03 12:03 -0800
Re: contradiction about the INFINITY macro Richard Damon <Richard@Damon-Family.org> - 2022-01-03 16:45 -0500
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-03 14:36 -0800
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-04 02:10 -0500
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 10:09 -0800
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-03 11:55 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-26 10:01 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 12:53 -0400
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-28 09:38 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-28 11:23 -0400
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-29 12:12 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-30 02:08 -0400
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-08 02:44 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-08 01:46 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-08 10:56 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-08 13:50 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-09 02:48 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-09 00:50 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-09 10:12 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-09 12:51 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-10 12:48 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-10 12:03 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-12 23:17 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-12 21:03 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-15 09:18 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-15 14:25 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-16 01:17 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-16 10:29 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-12-08 10:09 +0000
Re: contradiction about the INFINITY macro Derek Jones <derek@NOSPAM-knosof.co.uk> - 2021-11-16 11:32 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-16 10:35 -0500
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-11-09 07:13 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-10 13:16 +0000
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-11-10 08:02 -0800
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-10 15:01 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-13 00:30 +0000
Re: contradiction about the INFINITY macro Thomas Koenig <tkoenig@netcologne.de> - 2021-12-02 22:14 +0000
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-03 12:48 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-12 23:55 +0000
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-11-15 07:59 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-15 23:39 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-15 20:00 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-16 01:28 +0000
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-16 01:57 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-16 09:52 -0500
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-16 19:00 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-12-08 10:56 +0000
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-03 12:56 -0800
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-03 22:45 -0800
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 05:35 -0800
Re: contradiction about the INFINITY macro Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-30 03:20 +0100
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-10-09 20:05 +0000 |
| Message-ID | <20211009195154$ec8a@zira.vinc17.org> |
| In reply to | #6339 |
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)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-11 12:40 -0400 |
| Message-ID | <sk1pdj$5e3$4@dont-email.me> |
| In reply to | #6345 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-12-17 21:02 -0800 |
| Message-ID | <864k7633pr.fsf@linuxsc.com> |
| In reply to | #6345 |
Vincent Lefevre <vincent-news@vinc17.net> writes: > 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. [...] Not everyone agrees with this conclusion.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-10-08 00:02 -0700 |
| Message-ID | <86wnmoov7c.fsf@linuxsc.com> |
| In reply to | #6324 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-10-09 20:17 +0000 |
| Message-ID | <20211009201151$a68b@zira.vinc17.org> |
| In reply to | #6337 |
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)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-11 12:40 -0400 |
| Message-ID | <sk1pd2$5e3$3@dont-email.me> |
| In reply to | #6346 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-11 12:39 -0700 |
| Message-ID | <87fst75p15.fsf@nosuchdomain.example.com> |
| In reply to | #6349 |
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.
--
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 */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-11 21:04 -0400 |
| Message-ID | <sk2mv0$o9m$1@dont-email.me> |
| In reply to | #6351 |
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 ‘‘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 International Standard by the words ‘‘undefined behavior’’ 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-11 18:33 -0700 |
| Message-ID | <87bl3v58nv.fsf@nosuchdomain.example.com> |
| In reply to | #6352 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> 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 ‘‘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 International Standard
> by the words ‘‘undefined behavior’’ 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.
I don't disagree.
On the other hand, 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.
--
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 */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-03 12:03 -0800 |
| Message-ID | <86o84sy4ba.fsf@linuxsc.com> |
| In reply to | #6353 |
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".
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-01-03 16:45 -0500 |
| Message-ID | <W7KAJ.104391$Gco3.33852@fx01.iad> |
| In reply to | #6407 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-01-03 14:36 -0800 |
| Message-ID | <877dbg1m7b.fsf@nosuchdomain.example.com> |
| In reply to | #6410 |
Richard Damon <Richard@Damon-Family.org> writes:
> 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.
Explicitly? Where does the standard say that.
--
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 */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-01-04 02:10 -0500 |
| Message-ID | <sr0rsa$pg3$1@dont-email.me> |
| In reply to | #6410 |
On 1/3/22 4:45 PM, Richard Damon wrote: > 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. Where? The standard specifies that there are only two explicit ways whereby undefined behaviro is indicated: a "shall" or "shall not" that appears outside of a constraint or runtime-constraint, or the use of the words "undefined behavior". In which clause to is there a relevant use of "shall", "shall not" or "undefined behavior"? There's one implicit method, and that's "by the omission of any explicit definition of behavior", but I've argued that there is an explicit definition of the behavior that applies in this case. In the absence of a general statement that "a constraint shall be satisfied" or "a constraint shall not be violated" or "violation of a constraint has undefined behavior", or some other corresponding wording that qualifies as explicitly making the behavior undefined, the existence of that explicit definition of behavior is not erased by the constraint violation. If a constraint violation does not render an explicit definition of the behavior inapplicable, the only consequences of that violation are a mandatory diagnostic and permission to reject the program. Should an implementation choose not to reject the program, and should the resulting executable be run, the behavior of that program is still constrained by all of the requirements of the standard.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-17 10:09 -0800 |
| Message-ID | <86mtjus08r.fsf@linuxsc.com> |
| In reply to | #6410 |
Richard Damon <Richard@Damon-Family.org> writes: > 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. I don't think so. It may be the case that the C standard is meant to imply that a constraint violation will necessarily also result in undefined behavior, but AFAICT there is no explicit statement to that effect.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-03 11:55 -0800 |
| Message-ID | <86sfu4y4om.fsf@linuxsc.com> |
| In reply to | #6351 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 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",
Note that the C standard uses the word "constraint" in at least
two different senses. One is the sense of the definition given
above. Another is the sense of any stated restriction in a
'Constraints' section (and nothing else). AFAICT (I have not
tried to do a thorough search) the second sense never includes
a syntactic restriction.
> which is IMHO a bit vague.
Certainly it is at least ambiguous and subjective.
> 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.
This paragraph uses the word "behavior" in two different senses.
The C standard uses "behavior" to mean behavior in the abstract
machine, or sometimes to mean a description of behavior in the
abstract machine. In this sense the program has behavior whether
it is rejected or not: if it has defined behavior, then that is
the behavior, and if it has undefined behavior then the behavior is
"undefined behavior". The sentence "if the implementation rejects
the program, it has no behavior" uses the word behavior in the
sense of "run-time behavior", which is a different sense than how
"behavior" is used in the C standard. A C program has behavior,
in the sense that the C standard uses the term, whether it is
accepted or not, or even whether it is compiled or not.
> 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.
Since the implementations listed all have infinities, the value of
the constant is in the range of representable values for its type,
so no constraint is violated, and the behavior is always defined.
> 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.
Such cases occur often. Consider an implementation where SIZE_MAX
is 4294967295. If translating a program that has a declaration
static char blah[3221225472];
then the implementation is free to reject it, but the behavior is
defined whether the implementation accepts the program or rejects
it. Behavior is a property of the program, not the implementation.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-10-26 10:01 +0000 |
| Message-ID | <20211026094436$2e9f@zira.vinc17.org> |
| In reply to | #6349 |
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: > > 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. 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 that if the value is DBL_MAX, then it is in the range of representable values for its type, and the constraint is not violated. Note also that in case of overflow, "the nearest representable value" is not defined. IEEE 754 defines it as infinity. But what if Annex F is not supported and there is an infinity? Should the value still be the infinity or DBL_MAX (which is really the nearest, as the distance is finite, while the distance to the infinity is infinite). -- 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)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-26 12:53 -0400 |
| Message-ID | <sl9bqb$hf5$2@dont-email.me> |
| In reply to | #6358 |
On 10/26/21 6:01 AM, Vincent Lefevre wrote: > 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. 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. If the constant is greater than DBL_MAX, the "nearest representable value" is always DBL_MAX. The next smaller representable value is nextafter(DBL_MAX, 0). If infinity is representable, the "larger ... representable value" is infinity; otherwise, there is no "larger representable value", and one of the other two must be chosen. > 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.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-10-28 09:38 +0000 |
| Message-ID | <20211028091000$63ce@zira.vinc17.org> |
| In reply to | #6359 |
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. But this is probably not what is expected with floating-point constants. > > 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). -- 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)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-28 11:23 -0400 |
| Message-ID | <slef9t$98j$2@dont-email.me> |
| In reply to | #6360 |
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. However, on implementations that support infinities, it is allowed to be a positive infinity (footnote 245), and when __STDC_IEC_559__ is pre#defined by the implementation, it's required to be positive infinity (F10p2). Even if it isn't positive infinity, it is allowed to be DBL_MAX. DBL_MAX and positive infinity are two of the three options allowed by 6.4.4.2p4 for constants larger than DBL_MAX, in which case there's no conflict. If HUGE_VAL is not one of those three values, then 6.4.4.2p4 still applies, but 7.12.1p5 need not apply, since a match to the behavior of strtod() is only recommended, not required.. > 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). Agreed. As a result, the overflow exception should be signaled. However, the C standard mandates that "Floating constants are converted to internal format as if at translation-time. The conversion of a floating constant shall not raise an exceptional condition or a floating-point exception at execution time." (6.4.4.2p8). If an implementation chooses to do the conversion at translation-time, the exception would be raised only within the compiler, which has no obligation to do anything with it. The implementation could generate a diagnostic, but such a constant is not, in itself, justification for rejecting the program. Therefore, if an implementation chooses to defer actual conversion until run-time, it's required to produce the same results, which means it must clear that overflow exception before turning control over to the user code. > 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. As far as I can see, the value required by IEEE 754 is always one of the three values permitted by 6.4.4.2p4, so there's never a conflict. Are you aware of any? For hexadecimal floating point constants on systems with FLT_RADIX a power of 2, 6.4.4.2p4 only allows one value - the one that is correctly rounded - but that's precisely the same value that IEEE 754 requires.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-10-29 12:12 +0000 |
| Message-ID | <20211029105239$1291@zira.vinc17.org> |
| In reply to | #6361 |
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: > >>> 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. Yes, but this means that any implicit use of overflow is not perfectly clear. > > 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. 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. > > 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. 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. > >>> 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. 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)). -- 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)
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.std.c
csiph-web