[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] Is DBL_MAX "adjacent" to infinity? [Was: Two kinds of precision lo
From: |
Greg Chicares |
Subject: |
[lmi] Is DBL_MAX "adjacent" to infinity? [Was: Two kinds of precision loss] |
Date: |
Fri, 24 Mar 2017 19:36:44 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 |
On 2017-03-23 00:27, Greg Chicares wrote:
[...]
> Oh, and here's another question. What happens if you try
> static_cast<float>(DBL_MAX)?
> C++11 [4.8/1] says "If the source value is between two adjacent destination
> values, the result of the conversion is an implementation-defined choice of
> either of those values. Otherwise, the behavior is undefined." So is this
> cast UB? Or is DBL_MAX "adjacent" to infinity?
>
> And what about
> static_cast<float>((double)INFINITY)
> ? AIUI, the C and C++ standards supposedly defer to the floating-point
> standard, and IEEE 754-1985 [6.1] defines "conversion of an infinity into
> the same infinity in another format" as an operation that signals no
> exceptions, so I think this is supposed to be well defined. OTOH, it's
> not "between two adjacent destination values", so is it UB?
>
> Can it be that
> DBL_MAX is too big to convert to float, but
> INFINITY is not too big to " " "
> even though DBL_MAX < INFINITY?
I happened upon this:
https://www.securecoding.cert.org/confluence/display/c/FLP34-C.+Ensure+that+floating-point+conversions+are+within+range+of+the+new+type
It cites the C equivalents of C++11's [conv.double] and [conv.fpint],
exhorts us to avoid the undefined behavior noted there, and then says:
| This rule does not apply to demotions of floating-point types on
| implementations that support signed infinity, such as IEEE 754,
| as all values are within range.
OTOH, their "safe" version of
float f = whatever;
int i = (int) f;
signals an error if the value to be converted is
- out of range (determined by computing its logarithm), or
- subnormal
but does not check for NaN...so their advice seems unreliable.
- Re: [lmi] Is bourn_cast demonstrably correct? (+PATCH), (continued)
- Re: [lmi] Is bourn_cast demonstrably correct? (+PATCH), Vadim Zeitlin, 2017/03/20
- Re: [lmi] Is bourn_cast demonstrably correct? (+PATCH), Greg Chicares, 2017/03/20
- Re: [lmi] Is bourn_cast demonstrably correct?, Vadim Zeitlin, 2017/03/21
- Re: [lmi] Is bourn_cast demonstrably correct?, Greg Chicares, 2017/03/21
- Re: [lmi] Is bourn_cast demonstrably correct?, Vadim Zeitlin, 2017/03/21
- [lmi] Two kinds of precision loss [Was: Is bourn_cast demonstrably correct?], Greg Chicares, 2017/03/21
- Re: [lmi] Two kinds of precision loss, Vadim Zeitlin, 2017/03/22
- Re: [lmi] Two kinds of precision loss, Greg Chicares, 2017/03/22
- Re: [lmi] Two kinds of precision loss, Vadim Zeitlin, 2017/03/22
- Re: [lmi] Two kinds of precision loss, Greg Chicares, 2017/03/24
- [lmi] Is DBL_MAX "adjacent" to infinity? [Was: Two kinds of precision loss],
Greg Chicares <=
- Re: [lmi] Is DBL_MAX "adjacent" to infinity?, Vadim Zeitlin, 2017/03/24
- Re: [lmi] Is DBL_MAX "adjacent" to infinity?, Greg Chicares, 2017/03/24
- Re: [lmi] Is DBL_MAX "adjacent" to infinity?, Vadim Zeitlin, 2017/03/24