Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ucsd!chem.ucsd.edu!tps
From: tps@chem.ucsd.edu (Tom Stockfisch)
Newsgroups: comp.lang.c
Subject: Re: longjmp() from nested signal handlers
Message-ID: <147@chem.ucsd.EDU>
Date: 9 Apr 88 06:16:45 GMT
References: <4548@june.cs.washington.edu> <26739@amdahl.uts.amdahl.com> <3669@sdcc6.ucsd.EDU> <2555@ttrdc.UUCP>
Reply-To: tps@chem.ucsd.edu (Tom Stockfisch)
Organization: Chemistry Dept, UC San Diego
Lines: 43

In article <2555@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>In article ix426@sdcc6.ucsd.EDU (Tom Stockfisch) THAT'S ME writes:
># In article <26739@amdahl.uts.amdahl.com> nw@amdahl.uts.amdahl.com (Neal Weidenhofer) writes:
># >...  Using longjump from a signal handler ALWAYS results in
># >undefined behavior.
># 
># This *greatly* reduces the value of signals.
># I like to longjmp() back to a main processing loop on SIGINT.
>
>... a careful look at any protracted, iterative sequence
>of code that you want to be able to "bust out of" with a signal will reveal
>"high traffic" areas where you can put the check
>----------Dan Levy-------

I like your idea -- I'll give it a try.  But then I have this question:
in an ANSI C conforming program, am I allowed to do a longjmp() from
a handler for SIGFPE (floating point exception)?
I do this in numeric programs in the same way
as I've been handling SIGINT.  On some systems at least, the results
of *returning* from a SIGFPE handler is undefined.
For instance, on our Celerity machine there is the following warning
int the man entry for signal(3):

     "The assembler optimizations produce code that is not suit-
     able for restoration from floating point exceptions. The
     results of trying to restore from floating point exception
     into assembler-optimized code are not defined.

     "Restoration from floating point exception occurs if there is
     a signal handler for SIGFPE that executes a return state-
     ment, or if SIGFPE is being ignored. In these cases assem-
     bler optimization should be disabled.

     "If the default signal handling is used for SIGFPE, or if the
     SIGFPE signal handler always calls exit(3) or longjmp(3),
     assembler optimization can be used."

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.
-- 

|| Tom Stockfisch, UCSD Chemistry	tps@chem.ucsd.edu