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