longjmp out of signal handler
Richard Minner
rtm at christmas.UUCP
Tue Nov 27 19:17:12 AEST 1990
Henry Spencer wrote:
> ...here's a few sentences. :-)
> It is extremely difficult to guarantee that anything
> will work portably in signal handlers...
> ANSI C specifies as "undefined" almost any interaction with
> the world outside the signal handler except (a) calling signal() to reset
> that particular signal, and (b) assigning a variable to a flag of a specific
> (implementation-defined) type. In particular, it is impossible to guarantee
> that longjmp() will work from within a signal handler, because there are
> machines where it won't. This is really annoying in the presence of 4BSD's
> gratuitous breakage of the default semantics of signals, but there is
> nothing that can be done about it.
Thanks for the sentences Henry, BUT :-)
Is my funky old Dec 7, 1988 draft way off or what?
On longjmp, from 4.6.2.1:
As it bypasses the usual function call and return
mechanism, the longjmp function shall execute correctly in
contexts of interrupts, signals and any of their associated
functions. However, if the longjmp function is invoked
from a nested signal handler (that is, from a function
invoked as a result of a signal raised during the handling
of another signal), the behavior is undefined.
And 4.7.1.1 on the signal function states explicitly that a signal
handler may terminate by executing the longjmp function.
Is it the `no nesting' clause that kills it? If not, then I believe
that ANSI guarantees at least minimal support for longjmp'ing out of
handlers. Mind you, it's not something I intend to do every day, but
I had good reason to do it this one time and it bothers me when Chris
says (paraphrased) "even if you're careful, you've left reliability
and/or portability far behind". (In my case, portability is
secondary because the need is peculiar to my environment anyway,
but I'm very concerned about reliability.)
--
Richard Minner || {uunet,sun,well}!island!rtm (916) 736-1323 ||
|| Island Graphics Corporation Sacramento, CA ||
More information about the Comp.lang.c
mailing list