Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!hplabs!hpcea!hpfcdc!rml
From: rml@hpfcdc.HP.COM (Bob Lenk)
Newsgroups: comp.lang.c
Subject: Re: longjmp() from nested signal handlers
Message-ID: <5080024@hpfcdc.HP.COM>
Date: 19 Apr 88 23:40:21 GMT
References: <4548@june.cs.washington.edu>
Organization: HP Ft. Collins, Co.
Lines: 35

> 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 not off the track at all.  Quoting from section 4.7.1.1, page 121,
lines 16-18

	If the signal occurs other than as the result of calling the
	abort or raise function, the behavior is undefined if the
	signal handler calls any function in the standard library
	other than the signal function itself or ...

There are no exceptions for longjmp() or exit() (despite their mention
earlier on the same page).  This is correct, because their behavior is
indeed potentially incorrect if the signal has interrupted a call like
malloc(), atexit(), or one of the stdio functions.

Of course there are other times that calling exit() or longjmp() or
various other functions may indeed be safe, but there's no way using
just X3J11 primitives to determine that (in fact there's no way to
know for sure that a given signal is the result of abort() or raise();
consider a UNIX environment where another process has done a kill()
just before yours did the abort() or raise()).

POSIX addresses this less restictively, and provides primitives to
mask signals so that applications can know what a signal is (or is not)
interrupting.  Of course C must run on a wider range of implementations
than POSIX.

POSIX probably should require that longjmp() from a nested signal
handler work; it currently does not.

		Bob Lenk
		{ihnp4, hplabs}!hpfcla!rml
		rml%hpfcla@hplabs.hp.com