Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.questions
Subject: Re: question about signal
Message-ID: <6528@brl-smoke.ARPA>
Date: Wed, 7-Oct-87 21:39:06 EDT
Article-I.D.: brl-smok.6528
Posted: Wed Oct  7 21:39:06 1987
Date-Received: Sat, 10-Oct-87 12:20:31 EDT
References: <720001@hpclmar.HP.COM> <4248@udenva.UUCP> <1659@frog.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 21

In article <1659@frog.UUCP> john@frog.UUCP (John Woods, Software) writes:
-...  Presumably, your handler will either fix
-up the problem to allow the instruction to complete correctly (e.g., it
-would determine that one of the arguments is 0.0, print a message, stuff a
-1.0 into the register or temporary, and return)...

It is not in general possible to "fix up the problem" with portable C code.

You shouldn't print messages from signal handlers; the associated library
routines are in general non-reentrant due to possibly incomplete manipulation
of internal data structures when interrupted.

-... but in the *general* case the only useful thing a signal
-handler can do in this case is:
-my_FPE_handler() {
-	fprintf(stderr,"Ah, geez, a floating point exception happened!\n");
-	abort();
-}

No, it is often the case that an error flag can be set and a longjmp()
performed to reenter the application's main control loop.