Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: longjmp() from nested signal handlers
Message-ID: <7643@brl-smoke.ARPA>
Date: 9 Apr 88 23:38:35 GMT
References: <4548@june.cs.washington.edu> <26739@amdahl.uts.amdahl.com> <3669@sdcc6.ucsd.EDU> <2555@ttrdc.UUCP> <147@chem.ucsd.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 13

In article <147@chem.ucsd.EDU> tps@chem.ucsd.edu (Tom Stockfisch) writes:
>So it would seem SIGFPE could not be caught portably at all.  If you
>don't return, you violate ANSI, and if you don't exit() or longjmp(),
>the results are undefined.

Somewhere this issue got on the wrong track.  The current dpANS for C
permits longjmp() in the presence of signals as well as from a signal
handler; however, if invoked from a NESTED signal handler the behavior
is undefined.  This is simply a loophole to permit implementors who
would have a hard time making that work correctly to punt on it.  It
is hoped that implementors who can make it work correctly would do so.

SIGFPE can be caught portably, but be aware that there is no requirement
that a SIGFPE be generated, even for division by zero.