Bug 6792 - log1p() does not set errno n error
log1p() does not set errno n error
Status: NEW
Product: glibc
Classification: Unclassified
Component: math
unspecified
: P2 normal
: ---
Assigned To: Not yet assigned to anyone
:
: 5680 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-31 09:22 UTC by Michael Kerrisk
Modified: 2012-02-29 20:12 UTC (History)
2 users (show)

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


Attachments
test program (11.48 KB, text/plain)
2008-07-31 09:26 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-31 09:22:37 UTC
on a pole error or a domain error, log1p correctly raises an exception.  But
errno is not set.  It should be (respectively: ERANGE and EDOM)

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 09:26:04 UTC
Created attachment 2854 [details]
test program

Sample runs demonstrating the problem

$ /tmp/mt_log1p -- -1
errno == 0
fetestexcept() says:  FE_DIVBYZERO
log1p(-1.00000000000000000e+00)=-inf
0 FE_DIVBYZERO -inf

$ /tmp/mt_log1p -- -2
errno == 0
fetestexcept() says:  FE_INVALID
log1p(-2.00000000000000000e+00)=nan
0 FE_INVALID nan
Comment 2 Joseph Myers 2012-02-29 20:10:06 UTC
Confirmed with current sources, both x86 and x86_64.
Comment 3 Joseph Myers 2012-02-29 20:12:25 UTC
*** Bug 5680 has been marked as a duplicate of this bug. ***