Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.lang.c
Subject: Re: setjmp/longjmp
Message-ID: <5488@brl-tgr.ARPA>
Date: Sun, 28-Oct-84 22:01:16 EST
Article-I.D.: brl-tgr.5488
Posted: Sun Oct 28 22:01:16 1984
Date-Received: Tue, 30-Oct-84 01:16:31 EST
References: <3994@decwrl.UUCP>
Organization: Ballistic Research Lab
Lines: 27

> I see in previous articles enough information to convince me that we can't
> ask that all local variables by restored in longjmp to their values at the
> time of the setjmp, or to their last value in the routine containing the
> setjmp.  If there is a way to achieve this that is affordable, I'd far
> prefer it to my proposal.
> 
> So the problem comes down to characterizing which variables will be
> restored, and which will have random values.  I propose that only
> variables not altered since the setjmp call be guaranteed restored; other
> variables will have random values (not necessarily their last set value,
> the value they had at the time of the setjmp, or anything else).
> This is obviously achievable by simply saving and restoring all registers
> at setjmp/longjmp; on some hardware considerable improvements in this can
> be made.  
> 
> So, is this enough to be useful?  And, is more achievable transportably?

I agree with Dennis Ritchie that longjmp should resume after the call
to setjmp with all accessible data containing values as of the time of
the longjmp.  This can always be implemented, although some C run-time
designs seem to have not saved enough information on the call stack to
support longjmp.  Such implementations need to be changed.  Any system
where a subroutine call saves all the non-scratch registers (e.g., PDP-11,
Gould) is in good shape, as is any system where the number of registers
actually saved is recorded in the call frame (e.g. VAX).  Other systems
may have to have their calling sequences re-engineered, but that is what
they deserve for taking shortcuts.