Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!oberon!skat.usc.edu!blarson
From: blarson@skat.usc.edu (Bob Larson)
Newsgroups: comp.lang.c
Subject: Re: longjmp() from nested signal handlers
Message-ID: <8153@oberon.USC.EDU>
Date: 6 Apr 88 07:01:16 GMT
References: <4548@june.cs.washington.edu> <26739@amdahl.uts.amdahl.com>
Sender: news@oberon.USC.EDU
Reply-To: blarson@skat.usc.edu (Bob Larson)
Organization: USC AIS, Los Angeles
Lines: 27

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.
>My favorite example is to consider the case of the signal being
>raised while the program is in the middle of malloc(3) (for UN*X
>types--something equivalent if you're using VMS or some other
>OS).

>  There is NO WAY that your program is going to continue to
>run correctly after control has been forcibly removed from some
>routine while its internal tables are in an inconsistent state.

Just use mkon$p or mkonu$ (or the condition statment in a pl1 routine)
to create a handler for the cleanup$ condition.  Any non-local goto
("longjump") through the stack frame will cause the handler to be
called.  (Unless, of course, your not running primos.  :-) (There are
occasional advantages to huge microcode supported calling sequences.)
[Please note before flaming me: this to contrast the messages that
always assume vax/unix.  If you must flame, do so by mail.  I do agree
with the statement above if "portable" is inserted between "NO" and
"WAY".]

--
Bob Larson	Arpa: Blarson@Ecla.Usc.Edu	blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:	info-prime-request%fns1@ecla.usc.edu
			oberon!fns1!info-prime-request