strtof("1.40129846432481707092372958328991613128026194187651577175706828388979108268586060148663818836212158203125e-45", 0) sets errno to ERANGE (presumably considering this an underflow condition), despite the fact that exact denormal results are specified not to be considered an underflow. (The decimal string is the exact value of 0x1p-149, the smallest positive single precision float.)
It's not clear to me if this should set errno to ERANGE or not. IEEE
754-2008 (section 7.5) says:
In addition, under default exception handling for underflow, if the
rounded result is inexact - that is, it differs from what would have been
computed were both exponent range and precision unbounded - the underflow
flag shall be raised and the inexact (see 7.6) exception shall be
signaled. If the rounded result is exact, no flag is raised and no inexact
exception is signaled. This is the only case in this standard of an
exception signal receiving default handling that does not raise the
corresponding flag. Such an underflow signal has no observable effect
under default handling.
So does ERANGE for underflow correspond to the underflow exception being
signaled (in which case errno should be set to ERANGE) or to the flag
being raised (in which case errno should not be set to ERANGE)? I'll see
what the WG14 reflector thinks.
The language you cited seems self-contradictory, unless I'm missing some context. First it says that in the case we're interested in, "no flag is raised and no inexact exception is signaled." Then it goes on to talk about how this case is (pardon the pun) exceptional and about "an exception signal receiving default handling that does not raise the corresponding flag". I don't understand at all why the second half of that was written and what it's intended to mean.
With that said, I think the condition "no observable effect under default handling" would be contradicted by decimal-string-to-float conversion returning an indication of underflow.
As I understand it, the point of this case is that if you'd enabled
trapping on underflow exceptions, your trap handler would be called, but
without trapping enabled, this case will not set the underflow flag for
later testing of whether the flag is set. But for all other cases of
exceptions, the circumstances when a trap handler would be called when
trapping is enabled are exactly the circumstances the flag would be set.
Jim Thomas confirms underflow does mean inexact underflow (flag raised),
so this is indeed a bug. Also, as strtod is an operation producing a
binary result it should be consistent with the architecture-specific
choice of whether underflow is detected before or after rounding (for
round-to-nearest, the architecture-specific cases will those at least
three quarters of the way from the largest subnormal to the smallest
Fixed (including handling both before-rounding and after-rounding architectures properly) for 2.17 by:
Author: Joseph Myers <firstname.lastname@example.org>
Date: Tue Oct 30 13:51:27 2012 +0000
Fix strtod handling of underflow (bug 14047).