[lmi] Is DBL_MAX "adjacent" to infinity? [Was: Two kinds of precision loss]

[Greg Chicares]

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.