longjmp() in handler is evil (was Ambiguity in def...)

Richard Minner rtm at christmas.UUCP
Thu Oct 11 10:27:33 AEST 1990


In article <13914:Oct920:48:3290 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <:_A6T46 at xds13.ferranti.com> peter at ficc.ferranti.com (Peter da Silva) writes:
>> signals. In fact, calling longjmp from within signals is evil. The only
>> thing you should do within a signal routine is set a flag... anything
>> else is a bug waiting to happen.
>Correct.

(Note: my comma key is DEAD; please excuse the misuse of semi-colons.)

I'm hoping; from Dan's followup to alt.religion.computers; that this 
really is a religious issue; perhaps like goto's (i.e. it's evil in
that it is easy to do stupid things with it).  You see; I just did
this evil thing (longjmp in handler) for the very first time yesterday;
and I wanted to know if I really will go to hell for it and if so; why?

I tried using a flag; honest; but I'm catching SIGSEGV@ and the stupid
thing just got stuck in a loop and never could get to where I tested
the flag.  (Perhaps I missed something there; but the def of signal says
to me that "if func (the handler) executes a return statement ... the
program will resume execution at the point it was interrupted".  In my
case this appears to be right back at the "invalid access to storage".
Someone please correct me if I'm mistaken here.)  So; what I did is
basically:
	catch_sigsegv();	/* set handler */
	if (setjmp(env) == 0)
		[code that might cause SIGSEGV]
	else
		[caught SIGSEGV; set error etc.]
	release_sigsegv();	/* restore SIGSEGV */

and	void handler(sig) int sig; { longjmp(env [comma] 1); }

Anyway; it seems to work fine and I don't see where the hidden bug is.
Is this really a rotten thing to do?

------
@ Why catch SIGSEGV and do anything but abort()?  It has to do with
  mmap()'ing a file under Sun UNIX and running out of disk space.
  If you want details; send mail to the address below.


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



More information about the Comp.lang.c mailing list