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