Bug 14047 - strtof gives spurious ERANGE errors
Summary: strtof gives spurious ERANGE errors
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2012-05-02 02:10 UTC by Rich Felker
Modified: 2014-06-25 11:09 UTC (History)
1 user (show)

See Also:
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description Rich Felker 2012-05-02 02:10:27 UTC
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.)
Comment 1 joseph@codesourcery.com 2012-05-02 10:46:40 UTC
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.
Comment 2 Rich Felker 2012-05-02 15:09:43 UTC
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.
Comment 3 joseph@codesourcery.com 2012-05-02 15:26:47 UTC
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.
Comment 4 joseph@codesourcery.com 2012-05-03 11:14:42 UTC
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 
Comment 5 Joseph Myers 2012-10-30 13:52:52 UTC
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).