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 normal).
Fixed (including handling both before-rounding and after-rounding architectures properly) for 2.17 by: commit 2a27fd6dae3edec949deda9a55928a0e22c8a8ae Author: Joseph Myers <joseph@codesourcery.com> Date: Tue Oct 30 13:51:27 2012 +0000 Fix strtod handling of underflow (bug 14047).