Path: utzoo!attcan!uunet!island!grenada!christmas!rtm
From: rtm@christmas.UUCP (Richard Minner)
Newsgroups: comp.lang.c
Subject: longjmp out of signal handler (was Re: alloca() portability)
Summary: why is it so rotten?
Message-ID: <15@christmas.UUCP>
Date: 13 Nov 90 04:33:09 GMT
References: <14377@smoke.brl.mil> <9122@ncar.ucar.edu> <27537@mimsy.umd.edu> <1990Nov09.233527.7489@chinet.chi.il.us> <27608@mimsy.umd.edu>
Reply-To: rtm@island.uu.net (Richard Minner)
Organization: Island Graphics, Sacramento, California
Lines: 32

In article <27608@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) 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?
(You have so many :-)  (that was a compliment, by the way)

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?  I asked about
this a while back when (I believe) Peter da Silva said it was evil,
but no one answered.  If it's some kind of secret just say so and
I'll understand.

-- 
Richard Minner  || {uunet,sun,well}!island!rtm     (916) 736-1323 ||
                || Island Graphics Corporation     Sacramento, CA ||