setjmp: read the manual

[John Gilmore]

dmr says:
> V7, 4.[01]BSD, and SVr0 manuals include this sentence in the setjmp/longjmp
> documentation (setjmp(3): "All accessible data have values as of the time
> longjmp was called."  ...  (This is nontrivial, because the
> place where the register that contained x was saved can be anywhere in
> call chain.)
> 
> There is a very good reason for doing it this way: it makes
> register and automatic variables behave the same.
> 
> I checked the behavior on V8, 4.2BSD, and SVr2.  It works right
> (prints 2) on V8 and 4.2, works wrong (prints 1) on SV (on VAX, 3B20, 3B2).
> I don't have 4.2 or SVr2 manuals at hand so I don't know what they say.
> 
> 					Dennis Ritchie

There's a good reason for doing it the other way: efficiency.  The Sun
(4.2 on 68010's) setjmp(3) says:

       "All memory-bound data have values as of the time longjmp was called.
	The machine registers are restored to the values they had at the time
	setjmp was called.  But, because the register storage class is
	only a hint to the C compiler, variables declared as register
	variables may not necessarily be assigned to machine registers,
	so their values are unpredictable after a longjmp.  This is
	especially a problem for programmers trying to write machine-
	independent C routines."

We looked hard at this and decided to change the meaning of
setjmp/longjmp (to the above) rather than having EVERY function save
enough information to restore the registers to the desired state in
case the function's caller did a setjmp and some routine we call does a
longjmp.  On the VAX there is a call instruction that dumps all this
stuff on the stack for you (slowly; I understand a Modula compiler that
avoided the instruction sped itself up by 20%).  On the 68000 there is
no such whizzo instruction so we were forced to do it efficiently or
tell ourselves why not.  Longjmp wasn't a good enough reason.  Also,
some function calls internally generated by the compiler do not use the
standard calling sequence (again for efficiency) and this would have to
be abandoned too.

To fix a program that this breaks, you remove "register" declarations from
routines that call setjmp.  Not so bad.