Bug 165129 - fetestexcept(FE_ALL_EXCEPT) always returns 0
Summary: fetestexcept(FE_ALL_EXCEPT) always returns 0
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-04 15:59 UTC by John Ellson
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-08-06 08:22:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
C source illustrating bug (590 bytes, text/plain)
2005-08-04 15:59 UTC, John Ellson
no flags Details

Description John Ellson 2005-08-04 15:59:23 UTC
Description of problem:
fetestexcept(FE_ALL_EXCEPT) always returns 0

The fenv(3) man page states:
      The fetestexcept function returns a word in which the bits are set that
      were set in the argument excepts and for which the corresponding excep-
      tion is currently set.

And then later:
       glibc  2.2  supports  the  functions  feenableexcept  and
       fedisableexcept to set individual floating point traps, and fegetexcept
       to query the state.

So I think, by exclusion, that glibc is only providing a stub for fetestexcept()
which probably makes this bug report an RFE ?

Version-Release number of selected component (if applicable):
glibc-2.3.90-7
kernel-2.6.12-1.1448_FC5

How reproducible:
100%

Steps to Reproduce:
1. gcc fetestexcept_bug.c -lm
2. ./a.out
3.
  
Actual results:
SIGFPE is trapped, but fetestexcept fails to identify which FE_ error

Expected results:
In this test case I would expect fetestexcept to return FE_INVALID

Additional info:

Comment 1 John Ellson 2005-08-04 15:59:23 UTC
Created attachment 117459 [details]
C source illustrating bug

Comment 2 Jakub Jelinek 2005-08-06 08:22:32 UTC
That's misunderstanding.  Either you don't get signals and fetestexcept etc.
are usable, or you get signals and there are no accrued exceptions (as they are
signalled immediately).  You can use sigaction with SA_SIGINFO and look at
info->si_code to determine which exception happened.
In your case it will be FPE_FLTINV.



Note You need to log in before you can comment on or make changes to this bug.