Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site ISM780B.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!bellcore!decvax!yale!ISM780B!jim
From: jim@ISM780B.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Bug iwith setjmp/longjmp on Vax
Message-ID: <28500037@ISM780B.UUCP>
Date: Fri, 7-Jun-85 18:45:00 EDT
Article-I.D.: ISM780B.28500037
Posted: Fri Jun  7 18:45:00 1985
Date-Received: Tue, 11-Jun-85 02:36:26 EDT
References: <44700008@gypsy.UUCP>
Lines: 21
Nf-ID: #R:gypsy:44700008:ISM780B:28500037:000:1134
Nf-From: ISM780B!jim    Jun  7 18:45:00 1985


"Forward, into the past!" -- Firesign Theatre

If you longjmp into a routine that has already returned, just where do you
expect to be?  There is such a thing as stack discipline.
The routine that calls setjmp must be an ancestor of (or equal to, which
is broken on some implementations, such as pdp11 SysIII) the routine that
calls longjmp.  foo is not an ancestor of main.

The VAX 4.2BSD version is correct; it backtraces the stack so the register
variables are restored properly.  The Sun version is, technically,
incorrect; it saves the registers and sp in setjmp and simply restores
them in longjmp.  For details of why this is wrong, refer to the archives;
this has been discussed to death.  For details of why a correct implementation
appears too costly (extra overhead on every call), see same.  Also discussed
there was the simple, clever technique used by the Amsterdam Compiler Kit,
namely any routine that calls a routine called "setjmp" doesn't use register
variables; this doesn't work only if you call setjmp indirectly, which is
a rather bizarre and foolish thing to do.

-- Jim Balter, INTERACTIVE Systems (ima!jim)