Re: [lmi] Is DBL_MAX "adjacent" to infinity?

[Vadim Zeitlin]

On Fri, 24 Mar 2017 23:51:06 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-03-24 20:31, Vadim Zeitlin wrote:
GC> > On Fri, 24 Mar 2017 19:36:44 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> 
https://www.securecoding.cert.org/confluence/display/c/FLP34-C.+Ensure+that+floating-point+conversions+are+within+range+of+the+new+type
GC> [...]
GC> > GC> signals an error if the value to be converted is
GC> > GC>  - out of range (determined by computing its logarithm), or
GC> > GC>  - subnormal
GC> > GC> but does not check for NaN...so their advice seems unreliable.
GC> > 
GC> >  It's a bit hard to argue that NaN is "within range" (for any value of
GC> > "range"), so their rules does seem to be incomplete. But it doesn't really
GC> > invalidate the rest of it.
GC> 
GC> Why refuse to convert a subnormal value to integer? C99 [6.3.1.4/1] says
GC> to truncate (which eliminates the subnormality) and then check whether
GC> the integer part is representable in the integral part; if not, then and
GC> only then is it UB. But the integer part is zero, always representable,
GC> and UB cannot occur. Or have I misunderstood the meaning of this test
GC>   (f_a != 0.0F && fabsf(f_a) < FLT_MIN))
GC> to check whether 'f_a' is convertible to integer without UB?

 No, sorry, it was me: I didn't notice that subnormals resulted in an error
instead of just being converted to 0, but your interpretation is definitely
correct. Now that I see it too, I can't formulate any plausible hypothesis
as to why this would be a desirable behaviour however. My only guess was
that perhaps this coding standard recommended against using subnormals in
the first place, but this would be strange for recommendations for the
portable code (I don't think all CPUs provide a way to flash subnormals to
0, although Intel ones do) and I couldn't find any mention of it, so I
really don't know why do they do this.

 Sorry for not reading this correctly from the beginning,
VZ