[net.lang.c] setjmp

peterg@tekecs.UUCP (10/30/84)

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.


UUCP:	...!{ucbvax or decvax}!tektronix!tekecs!peterg
ARPA:	tekecs!peterg.tektronix @ udel-relay

gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/02/84)

> 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 can see the problem with registers, but why can't one count on autos
retaining their values??

jim@ISM780B.UUCP (11/03/84)

>/* Written  3:30 pm  Oct 31, 1984 by peterg@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)

peterg@tekecs.UUCP (11/07/84)

>> 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.

> I can see the problem with registers, but why can't one count on autos
> retaining their values??

I think the idea is that someone might design an optimizing compiler which
is smart enough to stick autos in unused registers.

-------- (And while I'm at it...)

How critical it is that all values are restored as of the time longjmp()
is called?? I use setjmp() and longjmp() to get out of signal handlers
and as a last resort to recover from disastrous errors. In both cases I
expect to reinitialize the world.

Suppose a certain piece of code did depend on local variables having values
as of the time longjmp() was called. (I haven't seen any such code in the
entire Berkeley 4.2 distribution.)  How hard would it be to modify the code
to remove the dependency? Would it be so hard that users would be willing
to pay a significant performance penalty on every procedure entry and exit
in many non-VAX implementations?

					Peter Galambos
					Tektronix, Inc.


UUCP:	...!{ucbvax or decvax}!tektronix!tekecs!peterg
ARPA:	tekecs!peterg.tektronix @ udel-relay