Thread: How to raise different floating point exceptions in C?

  1. #1
    Registered User
    Join Date
    Jun 2019
    Posts
    3

    Question How to raise different floating point exceptions in C?

    I am interested in raising floating point exceptions like Division by zero, Overflow, Underflow, etc.

    I am using functions in fenv.h and signal handling. Whenever, any floating point exception occurs,

    The problem seems like when inside the function catch_fpe ,the flags set by feraiseexcept somehow gets cleared and no condition is true.

    Code:
     
    #define _GNU_SOURCE
    #include <fenv.h>
    #include <stdio.h>
    #include <signal.h>
    #include <stdlib.h>
    void catch_fpe(int sig)
    {
      //#pragma STDC FENV_ACCESS ON 
      printf("i am in catch_fpe\n");
      if (fetestexcept(FE_OVERFLOW))
        printf("OVERFLOW\n");
      else if (fetestexcept(FE_UNDERFLOW))
        printf("UNDERFLOW\n");
      else if (fetestexcept(FE_DIVBYZERO))
        printf("DIVBYZERO\n");
      else if (fetestexcept(FE_INVALID))
        printf("INVALID OPERATION\n");
      else if (fetestexcept(FE_INEXACT))
        printf("INEXACT RESULT\n");
      exit(0);
    }
    
    int main()
    {
      feclearexcept(FE_ALL_EXCEPT);
      feenableexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW);
      signal(SIGFPE, catch_fpe);
      feraiseexcept(FE_DIVBYZERO);
    }
    Last edited by Salem; 06-27-2019 at 06:36 AM. Reason: Removed list, numbers are added automatically by code tags

  2. #2
    Registered User
    Join Date
    Feb 2019
    Posts
    436
    To deal with floating point exceptions is something very machine dependent... Notice the signal is being catched, but the kernel do not keep the floating point context in context switching, so the "default" fenv (in theory, available only when you declare the pragma STD FENV_ACESS ON), isn't available to the signal routine (I think, not sure).

    I suggest you avoid catching SIGFPE, since this is one of those "fatal error" signals. Deal with NaNs and Infs in your code to check the validity of your calculations...

    PS: POSIX standard (or is it SysV?) recommends to add 128 to the signal number, on exit. Your exit() call in the signal handler should be:
    Code:
    exit(128+sig);
    Last edited by flp1969; 06-27-2019 at 09:08 AM.

  3. #3
    Registered User
    Join Date
    Jun 2019
    Posts
    3
    Thanks for the reply @flp1969.
    I suggest you avoid catching SIGFPE, since this is one of those "fatal error" signals.
    I cannot do that. I will try any other method.

  4. #4
    Registered User
    Join Date
    Feb 2019
    Posts
    436
    Do a simple test... in an x86-64 machine, int the main function, get the MXCSR register (with _mm_getcsr()), unmask all exceptions [zeroing bits 8 to 12] and set again with _mm_setcsr())... In the signal handler get the MXCSR (after you do a division by zero, for example) and see the lower 5 bits (the exceptions)... they are all zero! Even worse: All the masks are back in place!

    Why?... Signals are interrupts. The OS (and the processor) won't allow control word changes between tasks/interrupts...

    All you will get is the interrupt, but cannot get why... not the easy way, at least...

  5. #5
    Registered User
    Join Date
    Jun 2019
    Posts
    3
    Why?... Signals are interrupts. The OS (and the processor) won't allow control word changes between tasks/interrupts...

    All you will get is the interrupt, but cannot get why... not the easy way, at least...
    I am sorry. But i am not able to understand what last line means.

  6. #6
    Registered User
    Join Date
    Feb 2019
    Posts
    436
    Quote Originally Posted by FrackeR011 View Post
    I am sorry. But i am not able to understand what last line means.
    What I meant is you can setup the floating point environment to catch SIGFPE. But cannot test for what triggered the signal (via fetestexcept())... fetestexcept() will always return 0, in this case...

    You'll get the signal (interrupt) - but won't get why the interrupt occur (fetestexcept() always 0).

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Floating point exceptions
    By Scarecrowm in forum C Programming
    Replies: 2
    Last Post: 10-18-2007, 08:57 AM
  2. Floating point Hex.
    By cstubbs50 in forum C Programming
    Replies: 4
    Last Post: 11-16-2005, 04:29 PM
  3. fixed point / floating point
    By confuted in forum Game Programming
    Replies: 4
    Last Post: 08-13-2002, 01:25 PM
  4. Floating point exceptions
    By Boris in forum C++ Programming
    Replies: 8
    Last Post: 11-19-2001, 08:32 AM
  5. Floating point faster than fixed-point
    By VirtualAce in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 11-08-2001, 11:34 PM

Tags for this Thread