longjmp out of signal handler (was Re: alloca() portability)

[Stanley Friesen]

In article <15 at christmas.UUCP> rtm at island.uu.net (Richard Minner) writes:
>Please Chris, could you spare a few paragraphs to elaborate on this?
>(You have so many :-)  (that was a compliment, by the way)

I am not Chris, but I will elaborate anyway.
The ANSI standard states that very few things are strictly conforming in
a signal handler.  In particular, a portable handler is mostly restricted to
updating volatile globals.

>I was compelled recently (by the devil no doubt) to do this thing.
>In short:
>	catch_sigsegv();
>	if (setjmp(sigsegv_jmp_buf) == 0)
>		<do naughty stuff that might cause SIGSEGV>
>	else
>		<make note of the SIGSEGV>
>	release_sigsegv();
>	...
>	void handler(sig) int sig;
>	{
>		<release the signal, check sig value...>
>		longjmp(sigsegv_jmp_buf, 1);
>	}
>
>Is this really all that unportable and/or unreliable?

Yes, it relies on a signal handling mechanism that does not have to be cleaned
up by the compiler/system before resuming normal code. (Such as operating
on a special stack, or leaving the hardware in a special no-interrupt state).

A more portable version is as follows:

	volatile int got_segv = 0;

	catch_sigsegv();
	<do naughty stuff that might cause SIGSEGV>
	if(got_segv)
	{
    		/* PROBLEM */
	}
	release_sigsegv();
	got_segv = 0;


	void handler(sig) int sig;
	{
		got_segv = 1;
	}

OOPS, even this is not portable, since it assumes that the return from
handler() does not restart the same instruction and generate a loop.


Answer, there is *no* portable solution.
-- 
---------------
uunet!tdatirv!sarima				(Stanley Friesen)