Bug 6786 - erfc() does not set errno for underflow
erfc() does not set errno for underflow
Status: NEW
Product: glibc
Classification: Unclassified
Component: math
unspecified
: P2 normal
: ---
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-30 14:52 UTC by Michael Kerrisk
Modified: 2012-02-29 21:06 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
test program (11.47 KB, text/plain)
2008-07-31 08:52 UTC, Michael Kerrisk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Kerrisk 2008-07-30 14:52:55 UTC
When erfc() is given an argument that causes underflow (e.g., erfc(106.9) on
x8632) it raises an underflow exception.  However, errno is not set.  It should
be set to ERANGE for this case.

Background: 
On error, many glibc math functions both set errno and raise an exception
(fetestexcept(3)).  For example, the following  function all do this: acos(),
asin(), cosh(), sinh(), acosh(), asinh(), exp(), exp2(), ldexp(), log(),
log10(), log2().  However, there is much inconsistency.  Some functions raise an
exception, but don't set errno.  Some functions set errno for some errors, but
not others.  A few set errno, but don't raise an exception.  This series of bug
reports documents deviations from what I consider the ideal: all functions
should BOTH set errno AND raise an exception for all errors.

All of these reports relate to tests on glibc 2.8 (as provided by SUSE 11.0).
Comment 1 Michael Kerrisk 2008-07-31 08:52:25 UTC
Created attachment 2851 [details]
test program

(I got the underflow value wrong in my initial report. I think 106.9 gives
underflow with the long double variant.  27 doies the trick for the double
version.)

Sample run showing problem:

$ /tmp/mt_erfc 27
errno == 0
fetestexcept() says:  FE_UNDERFLOW FE_INEXACT
erfc(2.70000000000000000e+01)=5.23704643935262924e-319
0 FE_UNDERFLOW subnormal
Comment 2 Joseph Myers 2012-02-29 21:06:48 UTC
Confirmed with current sources on both x86 and x86_64.