Behaviour of setjmp/longjmp and registers

[Doug Gwyn]

In article <8812 at alice.UUCP> ark at alice.UUCP (Andrew Koenig) writes:
>Once upon a time, the VAX setjmp worked by ...

I seem to recall at least three distinct implementations of setjmp/logjmp
in PDP-11 UNIX and something like four implementations in various versions
of VAX UNIX.  Reiser's was pretty good, but it would have been foolish to
rely on it for any sort of portable code, since other implementations
didn't necessarily work the same way.

>However, when it came to the ANSI committee, they decided it
>would be too hard to mandate this kind of implementation.
>So they took the least restrictive route possible -- longjmp
>doesn't have to work at all unless you beg it.

longjmp() has to do the essential "goto" action and return the
right value for the setjmp() invocation (which is constrained
to be in one of the contexts for which this can reasonably be
guaranteed).  After a longjmp, all accessible objects are
required to have the values they had when longjmp() (NOT
setjmp()) was invoked, except that cached autos inside the
function containing the setjmp are allowed to be out of sync.
That's to keep aggressive optimizers from having to treat
setjmp() invocations in a "magic" way.

Really, setjmp/longjmp is just a groady "goto" and should be
avoided for the same reasons as the ordinary "goto".  In fact
it is even more violent than an ordinary "goto", which is why
it has to be more loosely constrained.  I don't think I've
even seen a case in which setjmp/longjmp was the best way to
design code, let alone essential.  The nearest to a valid use
I know of is to allow a SIGINT to abort processing and fly
back to a main command loop (e.g. in the "ed" editor), but
even there the longjmp can cause stdio data structures to be
left in an inconsistent state.  Asynchronous concurrent
processes really need to be designed around better tools than
setjmp/longjmp.