setjmp(), register vars and the proposed standard

[peterg at tekecs.UUCP]

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