Mac Intel

Mikael Pettersson mikpe@REDACTED
Sat Aug 12 23:23:20 CEST 2006


On Sat, 12 Aug 2006 12:16:07 +0100, Mikael Pettersson wrote:
>Something trivial like this does raise SIGFPE:
>
>#include <signal.h>
>#include <stdlib.h>
>
>static void handler(int sig)
>{
>   _Exit(sig);
>}
>
>int main(int argc, char *argv[]) {
>         signal(SIGFPE, handler);
>         return argc / (argc - 1);
>}
>
>This program does _not_ raise SIGFPE at all!
>
>#include <signal.h>
>#include <stdlib.h>
>#include <string.h>
>#include <ucontext.h>
>#include <stdio.h>
>
>static void fpe_sig_action(int sig, siginfo_t *si, void *puc)
>{
>	printf("We are here!\n");
>	_Exit(sig);
>}
>
>double a = 3.23e133;
>double b = 3.57e257;
>double res;
>
>int main(int argc, char *argv[]) {
>	struct sigaction act;
>	memset(&act, 0, sizeof act);
>	act.sa_sigaction = fpe_sig_action;
>	act.sa_flags = SA_SIGINFO;
>	sigaction(SIGFPE, &act, NULL);
>   	return a * b;
>}

The first program performs an integer division by zero
whose failure cannot be masked. The second program performs
a floating-point multiply whose overflow by default is
masked in most environments. The two programs are completely
unrelated, apart from the fact that SIGFPE can report both
integer and floating-point errors.

The fpe-test.c code embedded in erts/configure.in shows how
to enable and catch floating-point exceptions for a number of
CPU/OS combinations.



More information about the erlang-questions mailing list