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 1 of 4 [1] 2 3 4 Next page →
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-09-30 01:47 +0000 |
| Subject | contradiction about the INFINITY macro |
| Message-ID | <20210930012112$48d9@zira.vinc17.org> |
In ISO C99:TC3 to C17, 7.12p4: The macro INFINITY expands to a constant expression of type float representing positive or unsigned infinity, if available; else to a positive constant of type float that overflows at translation time. Consider the "else" case. It is said that INFINITY expands to a constant and that it overflows, so that it is not in the range of representable values of float. But in 6.4.4p2: Each constant shall have a type and the value of a constant shall be in the range of representable values for its type. which would imply that INFINITY expands to a value in the range of representable values of float, contradicted by 7.12p4. Same issue in the current C2x draft N2596 (7.12p7 and 6.4.4p2). -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-29 19:05 -0700 |
| Message-ID | <87pmsqizrh.fsf@nosuchdomain.example.com> |
| In reply to | #6321 |
Vincent Lefevre <vincent-news@vinc17.net> writes:
> In ISO C99:TC3 to C17, 7.12p4:
>
> The macro INFINITY expands to a constant expression of type float
> representing positive or unsigned infinity, if available; else to a
> positive constant of type float that overflows at translation time.
>
> Consider the "else" case. It is said that INFINITY expands to a
> constant and that it overflows, so that it is not in the range of
> representable values of float.
>
> But in 6.4.4p2:
>
> Each constant shall have a type and the value of a constant shall
> be in the range of representable values for its type.
>
> which would imply that INFINITY expands to a value in the range of
> representable values of float, contradicted by 7.12p4.
>
> Same issue in the current C2x draft N2596 (7.12p7 and 6.4.4p2).
6.4.4p2 is a constraint. It doesn't make it impossible to write code
that violates that constraint.
If I understand correctly, it means that if an infinite value is not
available, then a program that refers to the INFINITY macro (in a
context where it's treated as a floating-point expression) violates that
constraint, resulting in a required diagnostic.
In fact I wrote the previous paragraph before I read the footnote on the
definition of INFINITY (N1570 7.12p4, footnote 229):
In this case, using INFINITY will violate the constraint in 6.4.4
and thus require a diagnostic.
There is no contradiction.
(I wonder if it would have been more useful to require that INFINITY not
be defined unless it can be defined as an actual infinity, but I haven't
given it a lot of thought.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-09-30 11:24 +0000 |
| Message-ID | <20210930105413$d6e8@zira.vinc17.org> |
| In reply to | #6322 |
In article <87pmsqizrh.fsf@nosuchdomain.example.com>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Vincent Lefevre <vincent-news@vinc17.net> writes: > > In ISO C99:TC3 to C17, 7.12p4: > > > > The macro INFINITY expands to a constant expression of type float > > representing positive or unsigned infinity, if available; else to a > > positive constant of type float that overflows at translation time. > > > > Consider the "else" case. It is said that INFINITY expands to a > > constant and that it overflows, so that it is not in the range of > > representable values of float. > > > > But in 6.4.4p2: > > > > Each constant shall have a type and the value of a constant shall > > be in the range of representable values for its type. > > > > which would imply that INFINITY expands to a value in the range of > > representable values of float, contradicted by 7.12p4. > > > > Same issue in the current C2x draft N2596 (7.12p7 and 6.4.4p2). > 6.4.4p2 is a constraint. It doesn't make it impossible to write code > that violates that constraint. Yes, but the issue here is that the standard mandates the implementation to violate a constraint, which is rather different from the case where a user writes buggy code. > If I understand correctly, it means that if an infinite value is not > available, then a program that refers to the INFINITY macro (in a > context where it's treated as a floating-point expression) violates that > constraint, resulting in a required diagnostic. I think the consequence is more than a diagnostic (which may yield a compilation failure in practice, BTW): AFAIK, the standard does not give a particular definition for "overflows at translation time", which would make it undefined behavior as usual for overflows. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-30 08:38 -0700 |
| Message-ID | <87lf3ehy4v.fsf@nosuchdomain.example.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:
>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>> > In ISO C99:TC3 to C17, 7.12p4:
>> >
>> > The macro INFINITY expands to a constant expression of type float
>> > representing positive or unsigned infinity, if available; else to a
>> > positive constant of type float that overflows at translation time.
>> >
>> > Consider the "else" case. It is said that INFINITY expands to a
>> > constant and that it overflows, so that it is not in the range of
>> > representable values of float.
>> >
>> > But in 6.4.4p2:
>> >
>> > Each constant shall have a type and the value of a constant shall
>> > be in the range of representable values for its type.
>> >
>> > which would imply that INFINITY expands to a value in the range of
>> > representable values of float, contradicted by 7.12p4.
>> >
>> > Same issue in the current C2x draft N2596 (7.12p7 and 6.4.4p2).
>
>> 6.4.4p2 is a constraint. It doesn't make it impossible to write code
>> that violates that constraint.
>
> Yes, but the issue here is that the standard mandates the implementation
> to violate a constraint, which is rather different from the case where a
> user writes buggy code.
No, it doesn't force the implementation to violate a constraint. It
says that a *program* that uses the INFINITY macro violates a constraint
(if the implementation doesn't support infinities).
Constraints apply to programs, not to implementations.
It means that if a program assumes that INFINITY is meaningful, and it's
compiled for a target system where it isn't, a diagnostic is guaranteed.
And again, it might have made more sense to say that INFINITY is not
defined for such implementations (as is done for the NAN macro), but
perhaps there was existing practice.
Here's what the C99 Rationale says:
What is INFINITY on machines that do not support infinity? It should
be defined along the lines of: #define INFINITY 9e99999f, where
there are enough 9s in the exponent so that the value is too large
to represent as a float, hence, violates the constraint of 6.4.4
Constants. In addition, the number classification macro FP_INFINITE
should not be defined. That allows an application to test for the
existance of FP_INFINITE as a safe way to determine if infinity is
supported; this is the feature test macro for support for infinity.
The problem with this is that the standard itself doesn't say that
FP_INFINITE is defined conditionally.
>> If I understand correctly, it means that if an infinite value is not
>> available, then a program that refers to the INFINITY macro (in a
>> context where it's treated as a floating-point expression) violates that
>> constraint, resulting in a required diagnostic.
>
> I think the consequence is more than a diagnostic (which may yield a
> compilation failure in practice, BTW): AFAIK, the standard does not
> give a particular definition for "overflows at translation time",
> which would make it undefined behavior as usual for overflows.
The meaning seems clear enough to me. It's a floating constant whose
mathematical value is outside the range of float, such as 9e99999f.
And yes, evaluating it (if the mandatory diagnostic does not cause
compilation to fail) causes undefined behavior. I think the intent is
that a portable program should check whether infinities are supported
before trying to evaluate INFINITY, but that intent is not well
reflected in the standard.
I don't think I have access to an implementation that doesn't support
infinities, so I don't know how this is handled in practice. Given the
near universal adoption of IEEE floating-point, it's probably reasonably
safe to assume that infinities are supported unless your program needs
to be painfully portable.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-10-01 09:05 +0000 |
| Message-ID | <20211001083755$efb3@zira.vinc17.org> |
| In reply to | #6325 |
In article <87lf3ehy4v.fsf@nosuchdomain.example.com>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > No, it doesn't force the implementation to violate a constraint. It > says that a *program* that uses the INFINITY macro violates a constraint > (if the implementation doesn't support infinities). Then this means that the C standard defines something the user must not use (except when __STDC_IEC_559__ is defined, as in this case, INFINITY is guaranteed to expand to the true infinity). > Constraints apply to programs, not to implementations. This is related, as programs will be transformed by an implementation. > It means that if a program assumes that INFINITY is meaningful, and it's > compiled for a target system where it isn't, a diagnostic is guaranteed. > And again, it might have made more sense to say that INFINITY is not > defined for such implementations (as is done for the NAN macro), but > perhaps there was existing practice. Yes, currently there is no way of fallback (without things like autoconf tests). Shouldn't the standard by changed to make INFINITY conditionally defined (if not required to expand to a true infinity)? This should not break existing programs. > Here's what the C99 Rationale says: > What is INFINITY on machines that do not support infinity? It should > be defined along the lines of: #define INFINITY 9e99999f, where > there are enough 9s in the exponent so that the value is too large > to represent as a float, hence, violates the constraint of 6.4.4 > Constants. In addition, the number classification macro FP_INFINITE > should not be defined. That allows an application to test for the > existance of FP_INFINITE as a safe way to determine if infinity is > supported; this is the feature test macro for support for infinity. > The problem with this is that the standard itself doesn't say that > FP_INFINITE is defined conditionally. Even if FP_INFINITE could be defined conditionally, this would not imply that INFINITY is usable, since for instance, long double may have an infinity but not float. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-01 12:20 -0700 |
| Message-ID | <877dewimc9.fsf@nosuchdomain.example.com> |
| In reply to | #6326 |
Vincent Lefevre <vincent-news@vinc17.net> writes:
> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
[...]
> Shouldn't the standard by changed to make INFINITY conditionally
> defined (if not required to expand to a true infinity)?
> This should not break existing programs.
I agree. NAN is conditionally defined "if and only if the
implementation supports quiet NaNs for the float type". I have no
idea why the same wasn't done for INFINITY -- unless, as I mentioned
upthread, there was existing practice. INFINITY was introduced
in C99. Perhaps there were pre-C99 implementations that defined
INFINITY as an extension in the way that's now specified in the
standard. That's just speculation, and I still think making it
conditional would have made more sense.
[...]
> Even if FP_INFINITE could be defined conditionally, this would not
> imply that INFINITY is usable, since for instance, long double may
> have an infinity but not float.
The standard only defines INFINITY and NAN for type float. I think the
implication is that it assumes either all floating types have NaNs
and/or infinities, or none do. That might be a valid assumption. (The
Alpha supports both VAX and IEEE floating-point, and I don't think VAX
FP supports infinities or NaNs, but I don't think an implementation
would use, for example, VAX FP for float and IEEE for double.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-10-04 09:26 +0000 |
| Message-ID | <20211004092110$b3e8@zira.vinc17.org> |
| In reply to | #6327 |
In article <877dewimc9.fsf@nosuchdomain.example.com>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Vincent Lefevre <vincent-news@vinc17.net> writes: > > In article <87lf3ehy4v.fsf@nosuchdomain.example.com>, > > Even if FP_INFINITE could be defined conditionally, this would not > > imply that INFINITY is usable, since for instance, long double may > > have an infinity but not float. > The standard only defines INFINITY and NAN for type float. I think the > implication is that it assumes either all floating types have NaNs > and/or infinities, or none do. That might be a valid assumption. But the standard doesn't say that explicitly. It even just says "if and only if the implementation supports quiet NaNs for the float type". If the intent were to have NaN support for all the FP types or none, why doesn't it say "... for the floating types" instead of "... for the float type"? -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-04 10:34 -0700 |
| Message-ID | <87r1d0g0dh.fsf@nosuchdomain.example.com> |
| In reply to | #6330 |
Vincent Lefevre <vincent-news@vinc17.net> writes:
> In article <877dewimc9.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>> > In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
>> > Even if FP_INFINITE could be defined conditionally, this would not
>> > imply that INFINITY is usable, since for instance, long double may
>> > have an infinity but not float.
>
>> The standard only defines INFINITY and NAN for type float. I think the
>> implication is that it assumes either all floating types have NaNs
>> and/or infinities, or none do. That might be a valid assumption.
>
> But the standard doesn't say that explicitly. It even just says
> "if and only if the implementation supports quiet NaNs for the
> float type". If the intent were to have NaN support for all the
> FP types or none, why doesn't it say "... for the floating types"
> instead of "... for the float type"?
Since the NAN macro is of type float (if it's define), it only makes
sense to define it that way. Presumably if an implementation had
NaN for float but not for double, it would define NAN.
IMHO it would have been better if the assumption that all floating
types behave similarly had been stated explicitly, and perhaps if there
were three NAN macros for the three floating-point types.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Geoff Clare <geoff@clare.See-My-Signature.invalid> |
|---|---|
| Date | 2021-10-05 13:53 +0100 |
| Message-ID | <ieut2i-07m.ln1@ID-313840.user.individual.net> |
| In reply to | #6331 |
Keith Thompson wrote: > Presumably if an implementation had > NaN for float but not for double, it would define NAN. > > IMHO it would have been better if the assumption that all floating > types behave similarly had been stated explicitly, and perhaps if there > were three NAN macros for the three floating-point types. NaN support for each floating type can be queried, and a NaN obtained if supported, by calling nanf(), nan(), and nanl(). -- Geoff Clare <netnews@gclare.org.uk>
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-10-06 00:12 +0000 |
| Message-ID | <20211006000739$eba9@zira.vinc17.org> |
| In reply to | #6333 |
In article <ieut2i-07m.ln1@ID-313840.user.individual.net>, Geoff Clare <geoff@clare.see-my-signature.invalid> wrote: > NaN support for each floating type can be queried, and a NaN > obtained if supported, by calling nanf(), nan(), and nanl(). But they are not required to be constant expressions, while the NAN macro expands to a constant expression. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-10-07 07:05 -0700 |
| Message-ID | <861r4xq6a8.fsf@linuxsc.com> |
| In reply to | #6331 |
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).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-07 07:51 -0700 |
| Message-ID | <87czog7uso.fsf@nosuchdomain.example.com> |
| In reply to | #6335 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>>> In article <877dewimc9.fsf@nosuchdomain.example.com>,
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>>>>
>>>>> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
>>>>> Even if FP_INFINITE could be defined conditionally, this would
>>>>> not imply that INFINITY is usable, since for instance, long
>>>>> double may have an infinity but not float.
>>>>
>>>> The standard only defines INFINITY and NAN for type float. I
>>>> think the implication is that it assumes either all floating types
>>>> have NaNs and/or infinities, or none do. That might be a valid
>>>> assumption.
>>>
>>> But the standard doesn't say that explicitly. It even just says
>>> "if and only if the implementation supports quiet NaNs for the
>>> float type". If the intent were to have NaN support for all the
>>> FP types or none, why doesn't it say "... for the floating types"
>>> instead of "... for the float type"?
>>
>> Since the NAN macro is of type float (if it's define), it only makes
>> sense to define it that way. Presumably if an implementation had
>> NaN for float but not for double, it would define NAN.
>
> If float has a NaN then so do double and long double, because of
> 6.2.5 paragraph 10. Similarly for infinity (or infinities).
Agreed. 6.2.5p10 says:
There are three real floating types, designated as float, double,
and long double. The set of values of the type float is a subset of
the set of values of the type double; the set of values of the type
double is a subset of the set of values of the type long double.
(No need to make everyone look it up.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-08 11:41 -0700 |
| Message-ID | <874k9r7419.fsf@nosuchdomain.example.com> |
| In reply to | #6336 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>>>> In article <877dewimc9.fsf@nosuchdomain.example.com>,
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>>>>>
>>>>>> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
>>>>>> Even if FP_INFINITE could be defined conditionally, this would
>>>>>> not imply that INFINITY is usable, since for instance, long
>>>>>> double may have an infinity but not float.
>>>>>
>>>>> The standard only defines INFINITY and NAN for type float. I
>>>>> think the implication is that it assumes either all floating types
>>>>> have NaNs and/or infinities, or none do. That might be a valid
>>>>> assumption.
>>>>
>>>> But the standard doesn't say that explicitly. It even just says
>>>> "if and only if the implementation supports quiet NaNs for the
>>>> float type". If the intent were to have NaN support for all the
>>>> FP types or none, why doesn't it say "... for the floating types"
>>>> instead of "... for the float type"?
>>>
>>> Since the NAN macro is of type float (if it's define), it only makes
>>> sense to define it that way. Presumably if an implementation had
>>> NaN for float but not for double, it would define NAN.
>>
>> If float has a NaN then so do double and long double, because of
>> 6.2.5 paragraph 10. Similarly for infinity (or infinities).
>
> Agreed. 6.2.5p10 says:
>
> There are three real floating types, designated as float, double,
> and long double. The set of values of the type float is a subset of
> the set of values of the type double; the set of values of the type
> double is a subset of the set of values of the type long double.
>
> (No need to make everyone look it up.)
I just noticed that leaves open the possibility, for example, that
double supports infinity but float doesn't.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-10-09 19:49 +0000 |
| Message-ID | <20211009194742$9114@zira.vinc17.org> |
| In reply to | #6341 |
In article <874k9r7419.fsf@nosuchdomain.example.com>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >>> Vincent Lefevre <vincent-news@vinc17.net> writes: > >>>> In article <877dewimc9.fsf@nosuchdomain.example.com>, > >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >>>>> Vincent Lefevre <vincent-news@vinc17.net> writes: > >>>>> > >>>>>> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>, > >>>>>> Even if FP_INFINITE could be defined conditionally, this would > >>>>>> not imply that INFINITY is usable, since for instance, long > >>>>>> double may have an infinity but not float. > >>>>> > >>>>> The standard only defines INFINITY and NAN for type float. I > >>>>> think the implication is that it assumes either all floating types > >>>>> have NaNs and/or infinities, or none do. That might be a valid > >>>>> assumption. > >>>> > >>>> But the standard doesn't say that explicitly. It even just says > >>>> "if and only if the implementation supports quiet NaNs for the > >>>> float type". If the intent were to have NaN support for all the > >>>> FP types or none, why doesn't it say "... for the floating types" > >>>> instead of "... for the float type"? > >>> > >>> Since the NAN macro is of type float (if it's define), it only makes > >>> sense to define it that way. Presumably if an implementation had > >>> NaN for float but not for double, it would define NAN. > >> > >> If float has a NaN then so do double and long double, because of > >> 6.2.5 paragraph 10. Similarly for infinity (or infinities). > > > > Agreed. 6.2.5p10 says: > > > > There are three real floating types, designated as float, double, > > and long double. The set of values of the type float is a subset of > > the set of values of the type double; the set of values of the type > > double is a subset of the set of values of the type long double. > > > > (No need to make everyone look it up.) > I just noticed that leaves open the possibility, for example, that > double supports infinity but float doesn't. This is what I had said above: "[...] for instance, long double may have an infinity but not float." -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-09 14:28 -0700 |
| Message-ID | <87o87x6g7o.fsf@nosuchdomain.example.com> |
| In reply to | #6344 |
Vincent Lefevre <vincent-news@vinc17.net> writes:
> In article <874k9r7419.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> > Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> >>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>> >>>> In article <877dewimc9.fsf@nosuchdomain.example.com>,
>> >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> >>>>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>> >>>>>
>> >>>>>> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
>> >>>>>> Even if FP_INFINITE could be defined conditionally, this would
>> >>>>>> not imply that INFINITY is usable, since for instance, long
>> >>>>>> double may have an infinity but not float.
>> >>>>>
>> >>>>> The standard only defines INFINITY and NAN for type float. I
>> >>>>> think the implication is that it assumes either all floating types
>> >>>>> have NaNs and/or infinities, or none do. That might be a valid
>> >>>>> assumption.
>> >>>>
>> >>>> But the standard doesn't say that explicitly. It even just says
>> >>>> "if and only if the implementation supports quiet NaNs for the
>> >>>> float type". If the intent were to have NaN support for all the
>> >>>> FP types or none, why doesn't it say "... for the floating types"
>> >>>> instead of "... for the float type"?
>> >>>
>> >>> Since the NAN macro is of type float (if it's define), it only makes
>> >>> sense to define it that way. Presumably if an implementation had
>> >>> NaN for float but not for double, it would define NAN.
>> >>
>> >> If float has a NaN then so do double and long double, because of
>> >> 6.2.5 paragraph 10. Similarly for infinity (or infinities).
>> >
>> > Agreed. 6.2.5p10 says:
>> >
>> > There are three real floating types, designated as float, double,
>> > and long double. The set of values of the type float is a subset of
>> > the set of values of the type double; the set of values of the type
>> > double is a subset of the set of values of the type long double.
>> >
>> > (No need to make everyone look it up.)
>
>> I just noticed that leaves open the possibility, for example, that
>> double supports infinity but float doesn't.
>
> This is what I had said above:
>
> "[...] for instance, long double may have an infinity but not float."
Yes. My initial assumption was that the three floating-point types
could independently have or not have infinities. Tim cited 6.2.5p10,
which implies that if float has infinities, then the wider types do
also. (I wonder if the authors had infinities and NaNs in mind when
they wrote that, but the implication is still there.)
If long double has infinities, then float and double may or may not.
If float has infinities, then double and long double must.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Jakob Bohm <jb-usenet@wisemo.com.invalid> |
|---|---|
| Date | 2021-10-01 22:55 +0200 |
| Message-ID | <58udnbOX8PAx6Mr8nZ2dnUU78aHNnZ2d@giganews.com> |
| In reply to | #6326 |
On 2021-10-01 11:05, Vincent Lefevre wrote: > In article <87lf3ehy4v.fsf@nosuchdomain.example.com>, > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >> No, it doesn't force the implementation to violate a constraint. It >> says that a *program* that uses the INFINITY macro violates a constraint >> (if the implementation doesn't support infinities). > > Then this means that the C standard defines something the user must > not use (except when __STDC_IEC_559__ is defined, as in this case, > INFINITY is guaranteed to expand to the true infinity). > >> Constraints apply to programs, not to implementations. > > This is related, as programs will be transformed by an implementation. > >> It means that if a program assumes that INFINITY is meaningful, and it's >> compiled for a target system where it isn't, a diagnostic is guaranteed. >> And again, it might have made more sense to say that INFINITY is not >> defined for such implementations (as is done for the NAN macro), but >> perhaps there was existing practice. > > Yes, currently there is no way of fallback (without things like > autoconf tests). > > Shouldn't the standard by changed to make INFINITY conditionally > defined (if not required to expand to a true infinity)? > This should not break existing programs. The fallback is to test for defined(FP_INFINITE), see below. > >> Here's what the C99 Rationale says: > >> What is INFINITY on machines that do not support infinity? It should >> be defined along the lines of: #define INFINITY 9e99999f, where >> there are enough 9s in the exponent so that the value is too large >> to represent as a float, hence, violates the constraint of 6.4.4 >> Constants. In addition, the number classification macro FP_INFINITE >> should not be defined. That allows an application to test for the >> existance of FP_INFINITE as a safe way to determine if infinity is >> supported; this is the feature test macro for support for infinity. > >> The problem with this is that the standard itself doesn't say that >> FP_INFINITE is defined conditionally. > > Even if FP_INFINITE could be defined conditionally, this would not > imply that INFINITY is usable, since for instance, long double may > have an infinity but not float. > I don't know if there is a set of similar macros for double and long double types buried somewhere in the standard. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-01 14:26 -0700 |
| Message-ID | <87tui0h1xq.fsf@nosuchdomain.example.com> |
| In reply to | #6328 |
Jakob Bohm <jb-usenet@wisemo.com.invalid> writes:
> On 2021-10-01 11:05, Vincent Lefevre wrote:
>> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>> No, it doesn't force the implementation to violate a constraint. It
>>> says that a *program* that uses the INFINITY macro violates a constraint
>>> (if the implementation doesn't support infinities).
>> Then this means that the C standard defines something the user must
>> not use (except when __STDC_IEC_559__ is defined, as in this case,
>> INFINITY is guaranteed to expand to the true infinity).
>>
>>> Constraints apply to programs, not to implementations.
>> This is related, as programs will be transformed by an
>> implementation.
>>
>>> It means that if a program assumes that INFINITY is meaningful, and it's
>>> compiled for a target system where it isn't, a diagnostic is guaranteed.
>>> And again, it might have made more sense to say that INFINITY is not
>>> defined for such implementations (as is done for the NAN macro), but
>>> perhaps there was existing practice.
>> Yes, currently there is no way of fallback (without things like
>> autoconf tests).
>> Shouldn't the standard by changed to make INFINITY conditionally
>> defined (if not required to expand to a true infinity)?
>> This should not break existing programs.
>
> The fallback is to test for defined(FP_INFINITE), see below.
>
>>
>>> Here's what the C99 Rationale says:
>>
>>> What is INFINITY on machines that do not support infinity? It should
>>> be defined along the lines of: #define INFINITY 9e99999f, where
>>> there are enough 9s in the exponent so that the value is too large
>>> to represent as a float, hence, violates the constraint of 6.4.4
>>> Constants. In addition, the number classification macro FP_INFINITE
>>> should not be defined. That allows an application to test for the
>>> existance of FP_INFINITE as a safe way to determine if infinity is
>>> supported; this is the feature test macro for support for infinity.
>>
>>> The problem with this is that the standard itself doesn't say that
>>> FP_INFINITE is defined conditionally.
>> Even if FP_INFINITE could be defined conditionally, this would not
>> imply that INFINITY is usable, since for instance, long double may
>> have an infinity but not float.
>>
>
> I don't know if there is a set of similar macros for double and long
> double types buried somewhere in the standard.
The INFINITY and NAN macros are defined only for float. I think the
assumption is that either all floating-point types support infinities,
or none do, and likewise for NaNs. On the other hand, fpclassify() is a
macro that can be applied to an expression of any floating-point type.
The problem, as I said, is that the standard doesn't say that
FP_INFINITE is conditionally defined. Since they're specified in the
same section that explicitly says that NAN is conditionally defined, I
think the only reasonable reading of the standard's wording is that
FP_INFINITE is defined whether infinities are supported or not.
If they're not, it just means that fpclassify() will never return
FP_INFINITE and isinf() always returns 0.
The author(s) of the Rationale obviously *thought* that FP_INFINITE is
conditionally defined. They were mistaken. The Rationale itself makes
it clear that the Standard, not the Rationale, is what defines the
language.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-10-08 08:30 -0700 |
| Message-ID | <86sfxbpm9d.fsf@linuxsc.com> |
| In reply to | #6326 |
Vincent Lefevre <vincent-news@vinc17.net> writes:
> In article <87lf3ehy4v.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
>> It means that if a program assumes that INFINITY is meaningful, and
>> it's compiled for a target system where it isn't, a diagnostic is
>> guaranteed. And again, it might have made more sense to say that
>> INFINITY is not defined for such implementations (as is done for
>> the NAN macro), but perhaps there was existing practice.
>
> Yes, currently there is no way of fallback (without things like
> autoconf tests).
>
> Shouldn't the standard by changed to make INFINITY conditionally
> defined (if not required to expand to a true infinity)? [...]
To me it seems better for INFINITY to be defined as it is rather
than being conditionally defined. If what is needed is really an
infinite value, just write INFINITY and the code either works or
compiling it gives a diagnostic. If what is needed is just a very
large value, write HUGE_VAL (or HUGE_VALF or HUGE_VALL, depending)
and the code works whether infinite floating-point values are
supported or not. If it's important that infinite values be
supported but we don't want to risk a compilation failure, use
HUGE_VAL combined with an assertion
assert( HUGE_VAL == HUGE_VAL/2 );
Alternatively, use INFINITY only in one small .c file, and give
other sources a make dependency for a successful compilation
(with of course a -pedantic-errors option) of that .c file. I
don't see that having INFINITY be conditionally defined buys
anything, except to more or less force use of #if/#else/#endif
blocks in the preprocessor. I don't mind using the preprocessor
when there is a good reason to do so, but here I don't see one.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-08 11:40 -0700 |
| Message-ID | <878rz3743a.fsf@nosuchdomain.example.com> |
| In reply to | #6339 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Vincent Lefevre <vincent-news@vinc17.net> writes:
[...]
>> Shouldn't the standard by changed to make INFINITY conditionally
>> defined (if not required to expand to a true infinity)? [...]
>
> To me it seems better for INFINITY to be defined as it is rather
> than being conditionally defined. If what is needed is really an
> infinite value, just write INFINITY and the code either works or
> compiling it gives a diagnostic. If what is needed is just a very
> large value, write HUGE_VAL (or HUGE_VALF or HUGE_VALL, depending)
> and the code works whether infinite floating-point values are
> supported or not. If it's important that infinite values be
> supported but we don't want to risk a compilation failure, use
> HUGE_VAL combined with an assertion
>
> assert( HUGE_VAL == HUGE_VAL/2 );
>
> Alternatively, use INFINITY only in one small .c file, and give
> other sources a make dependency for a successful compilation
> (with of course a -pedantic-errors option) of that .c file. I
> don't see that having INFINITY be conditionally defined buys
> anything, except to more or less force use of #if/#else/#endif
> blocks in the preprocessor. I don't mind using the preprocessor
> when there is a good reason to do so, but here I don't see one.
I don't see how that's better than conditionally defining INFINITY.
If you really need an infinite value, just write INFINITY and the code
either works or compiling it gives a *clearer* diagnostic for the
undeclared identifier.
If you need to test whether infinities are supported, #ifdef INFINITY is
a lot clearer than assert( HUGE_VAL == HUGE_VAL/2 ).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-12-17 21:00 -0800 |
| Message-ID | <86bl1e33tn.fsf@linuxsc.com> |
| In reply to | #6340 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > 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. It's better only in the sense that it works with the existing C standards, and may give acceptable results in practice.
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | comp.std.c
csiph-web