views:

825

answers:

6

I have a program which deliberately performs a divide by zero (and stores the result in a volatile variable) in order to halt in certain circumstances. However, I'd like to be able to disable this halting, without changing the macro that performs the division by zero.

Is there any way to ignore it?

I've tried using

#include <signal.h>
...
int main(void) {
  signal(SIGFPE, SIG_IGN);
  ...
}

but it still dies with the message "Floating point exception (core dumped)".

I don't actually use the value, so I don't really care what's assigned to the variable; 0, random, undefined...

EDIT: I know this is not the most portable, but it's intended for an embedded device which runs on many different OSes. The default halt action is to divide by zero; other platforms require different tricks to force a watchdog induced reboot (such as an infinite loop with interrupts disabled). For a PC (linux) test environment, I wanted to disable the halt on division by zero without relying on things like assert.

+3  A: 

Why would you deliberately perform a divide by zero to halt? Couldn't you exit(-1) or some equivalent?

Especially if you don't need the result of the divide by 0, this just doesn't make sense.

lc
Because it's for code generally used in an embedded device; I want to halt the device and have the watchdog reboot in most cases
Mikeage
is there a reason you can't send a SIGQUIT instead of dividing by zero?
lc
For this particular test, I simply removed the divide by zero and used a different implementation. For the embedded application, I still use the divide by zero (most platforms are not POSIX), but there I don't have the requirement to disable it.
Mikeage
A: 

This is not portable, but on x86 you can by controlling the FPU:

Using gcc on Linux (I'm sure other compilers have similar facilities):

#include <fpu_control.h>

_FPU_SETCW (_FPU_DEFAULT);

Since _FPU_DEFAULT defaults to _FPU_MASK_ZM set (ZM stands for Zero-Divide-Mask).

nimrodm
A: 

Could you cause the program to exit through a less contrived expression? For instance:

#include <signal.h>

#ifdef DEBUG
#define DIE_HERE raise(SIGFPE)
#else
#define DIE_HERE
#endif

I'd be hesitant to override the default behavior, lest some other part of your program divide by zero unintentionally. Alternatively, if you're forcing it to exit this way in order to get a core dump, you may want to look into using breakpoints within a debugger. Or, if you're on a system with the gdb debugger, the gcore utility may be useful.

Kim Reece
+2  A: 
Cirno de Bergerac
+2  A: 

Check the return value of

signal(SIGFPE, SIG_IGN);

If you get SIG_ERR, check the value of errno to find out what went wrong. That's as much as you can do portably.

I know you don't want to change the divide by zero, but it's nonportable and counterintuitive. You want to coredump if some condition occurs, but be able to disable this behaviour without editing code? Use assert and NDEBUG.

fizzer
0 and 0. No help there.
Mikeage
A: 

If you have control over the crashing code, then I'd also recommend to change the code to die some other way. If you don't, you could try to install an empty signal handler instead (i.e. use signal(SIGFPE, &EmptyFunction)), but you're still relying on undefined behaviour, so there's no guarantee it will still work on other systems, or other kernel or C library versions.

Doug