Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: longjmp out of signal handler (was Re: alloca() portability)
Message-ID: <1990Nov16.181436.21736@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <14377@smoke.brl.mil> <9122@ncar.ucar.edu> <27537@mimsy.umd.edu> <1990Nov09.233527.7489@chinet.chi.il.us> <27608@mimsy.umd.edu> <15@christmas.UUCP>
Date: Fri, 16 Nov 90 18:14:36 GMT

In article <15@christmas.UUCP> rtm@island.uu.net (Richard Minner) writes:
>>As soon as you mention `longjmp out of signal handlers' you have left
>>either portability or reliability far behind (even if you are careful,
>>doing *anything* with signals tends to make software unportable).
>>
>Please Chris, could you spare a few paragraphs to elaborate on this?

In case Chris doesn't have paragraphs to spare right now, here's a few
sentences. :-)  It is extremely difficult to guarantee that anything
will work portably in signal handlers, because the stranger C environments
put bizarre restrictions on them due to difficulties with calling conventions
and the like.  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.
-- 
"I don't *want* to be normal!"         | Henry Spencer at U of Toronto Zoology
"Not to worry."                        |  henry@zoo.toronto.edu   utzoo!henry