Ambiguity in definition of setjmp/longjmp makes them much less useful

[Cameron Simpson]

>From article <TOM.90Oct8071803 at hcx2.ssd.csd.harris.com>, by tom at ssd.csd.harris.com (Tom Horsley):
| Personally, I believe that compilers should support setjmp() as a special
| construct - simply making might-goto arcs from every other function call to
| a point immediately following any setjmp() calls would add enough
| information to the flow graph for an optimizing compiler to recognize the
| funny lifetimes that registers might have and volatile would only be needed
| for variables that interact with signal handling code (since a signal
| can happen anywhere in the program, not just at a function call).

But think about what happens when you write
	sigfn(sig)
	{
		longjmp(foojmpbuf,1);
		/*NOTREACHED*/
	}
Since, as you say, a signal can happen anywhere then there is now a might-goto
arc from _every_ point in the program which can conceivably be called from
within any function which uses foojmpbuf as a jump buffer. This could easily
include large stretches of the C library. It gets much worse if something as
bizarre as the following is done:
	jmp_buf	*current_restore_point=NULL;

	sigfn(sig)
	{
		if (current_restore_point == NULL)
			fprintf(stderr,"ouch! - uncaught signal %d\n",sig);
		else
		longjmp(*current_restore_point,sig);
	}
And then set/clear current_restore_point around various bits of code. This
puts might-goto arcs from almost every bit of code unless your compiler is
almost precognitive, and the programmer aware of this effect.

My preferred solution is not to use setjmp/longjmp at all. Of course, it
isn't always possible. BSD's non-switch-off-able restartable system calls
(like a read from a tty) irk me particularly in this regard.
	- Cameron Simpson
	  cameron at spectrum.cs.unsw.oz.au

"If it can't be turned off, it's not a feature." Karl Huer (I think).