setjmp(), register vars and the prop

[jim at ISM780B.UUCP]

>/* Written  3:30 pm  Oct 31, 1984 by peterg at tekecs in ISM780B:net.lang.c */
>/* ---------- "setjmp(), register vars and the prop" ---------- */
>This is how the library subsection of the proposed ANSI standard
>reads for setjmp()/longjmp():
>
>> All accessible objects have value as of the time longjmp was called,
>> except for objects of storage class auto or register whose values
>> have been changed between the setjmp and longjmp calls. These values
>> are undefined.
>
>Given that many processors don't automatically push any kind of register
>mask on the stack (as VAXen do) this seems like a 'safe and sane' approach.

I assume the restriction on auto variables is to allow compilers to
keep them in registers part or all of the time.

I think the restriction should only be to variables of the routine that
called setjmp, and to modifications made within that routine, so that there
is no implication that in

	foo() { int x; bar(&x); ...}
	bar(xp) int *x; {int y; *xp = 3; setjmp(jmpbuf); crud(&y); ...}

or

the value of y is undefined after the longjmp if it was modified by crud,
or that the value of x is undefined after the longjmp.

For complete safety, I suggest that setjmp and longjmp be used only in the
following fashion:

	if( setjmp(jmpbuf) == 0 )
	    abortablefunc(...);
	else
	    ...

where longjmp will only be called as a descendant of abortablefunc.
This is much more structured and understandable than arbitrary global jumps.
It guarantees that no local variables are changed between the time of
the setjmp and the longjmp (barring side effects in the evaluation of
abortablefunc's args, e.g., abortablefunc(a = b, *p++)).

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