Returning From Catching A Floating Point Exception

Question

So, I am trying to return from a floating point exception, but my code keeps looping instead. I can actually exit the process, but what I want to do is return and redo the calculation that causes the floating point error.

The reason the FPE occurs is because I have a random number generator that generates coefficients for a polynomial. Using some LAPACK functions, I solve for the roots and do some other things. Somewhere in this math intensive chain, a floating point exception occurs. When this happens, what I want to do is increment the random number generator state, and try again until the coefficients are such that the error doesn't materialize, as it usually doesn't, but very rarely does and causes catastrophic results.

So I wrote a simple test program to learn how to work with signals. It is below:

In exceptions.h

#ifndef EXCEPTIONS_H
#define EXCEPTIONS_H

#define _GNU_SOURCE

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <math.h>
#include <errno.h>
#include <float.h>
#include <fenv.h>

void overflow_handler(int);

#endif // EXCEPTIONS_H //

In exceptions.c

#include "exceptions.h"

void overflow_handler(int signal_number)
{
    if (feclearexcept(FE_OVERFLOW | FE_UNDERFLOW | FE_DIVBYZERO | FE_INVALID)){
        fprintf(stdout, "Nothing Cleared!\n");
    }
    else{
        fprintf(stdout, "All Cleared!\n");
    }

    return;
}

In main.c

#include "exceptions.h"


int main(void)
{
    int failure;
    float oops;

    //===Enable Exceptions===//
    failure = 1;
    failure = feenableexcept(FE_OVERFLOW | FE_UNDERFLOW | FE_DIVBYZERO | FE_INVALID);
    if (failure){
        fprintf(stdout, "FE ENABLE EXCEPTIONS FAILED!\n");
    }

    //===Create Error Handler===//
    signal(SIGFPE, overflow_handler);

    //===Raise Exception===//
    oops = exp(-708.5);
    fprintf(stdout, "Oops: %f\n", oops);

    return 0;
}

The Makefile

#===General Variables===#
CC=gcc
CFLAGS=-Wall -Wextra -g3 -Ofast

#===The Rules===#
all: makeAll

makeAll: makeExceptions makeMain
    $(CC) $(CFLAGS) exceptions.o main.o -o exceptions -ldl -lm

makeMain: main.c 
    $(CC) $(CFLAGS) -c main.c -o main.o

makeExceptions: exceptions.c exceptions.h
    $(CC) $(CFLAGS) -c exceptions.c -o exceptions.o 

.PHONY: clean

clean:
    rm -f *~ *.o

Why doesn't this program terminate when I am clearing the exceptions, supposedly successfully? What do I have to do in order to return to the main, and exit?

If I can do this, I can put code in between returning and exiting, and do something after the FPE has been caught. I think that I will set some sort of flag, and then clear all most recent info in the data structures, redo the calculation etc based on whether or not that flag is set. The point is, the real program must not abort nor loop forever, but instead, must handle the exception and keep going.

Help?

Answer 1

"division by zero", overflow/underflow, etc. result in undefined behaviour in the first place. If the system, however, generates a signal for this, the effect of UB is "suspended". The signal handler takes over instead. But if the handler returns, the effect of UB will "resume".

Therefore, the standard disallows returning from such a situation.

Just think: How would the program have to recover from e.g. DIV0? The abstract machine has no idea about FPU registers or status flags, and even if - what result would have to be generated?

C also has no provisions to unroll the stack properly like C++.

Note also, that generating signals for arithmetic exceptions is optional, so there is no guarantee a signal will actually be generated. The handler is mostly meant to notify about the event and possibly clean up external resources.

Behaviour is different for signals which do not origin from undefined behaviour, but just interrupt program execution. This is well defined as the program state is well-defined.

Edit:

If you have to rely on the program to continue under all circumstances, you hae to check all arguments of arithmetic operations before doing the actual operation and/or use safe operations only (re-order, use larger intermediate types, etc.). One exaple for integers might be to use unsigned instead of signed integers, as for those overflow-behavior is well-defined (wrap), so intermediate results overflowing will not make trouble as long as that is corrected afterwards and the wrap is not too much. (Disclaimer: that does not always work, of course).

Update:

While I am still not completely sure, according to comments, the standard might allow, for a hosted environment at least, to use LIA-1 traps and to recover from them (see Annex H. As these are not necessarily precise, I suspect recovery is not possible under all circumstances. Also, math.h might present additional aspects which have to be carefully evaluated.

Finally: I still think there is nothing gained with such approach, but some uncertainty added compared to using safe algorithms. It would be different, if there wer not so much different components involved. For a bare-metal embedded system, the view might be completely different.