Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site decwrl.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!zehntel!dual!amd!decwrl!dec-rhea!dec-mrvax!ddb
From: ddb@mrvax.DEC (DAVID DYER-BENNET MRO1-2/L14 DTN 231-4076)
Newsgroups: net.lang.c
Subject: setjmp/longjmp
Message-ID: <3994@decwrl.UUCP>
Date: Wed, 24-Oct-84 11:33:23 EDT
Article-I.D.: decwrl.3994
Posted: Wed Oct 24 11:33:23 1984
Date-Received: Fri, 26-Oct-84 03:30:33 EDT
Sender: daemon@decwrl.UUCP
Organization: DEC Engineering Network
Lines: 29

I will propose a semantics for setjmp/longjmp that is compiler-independent,
implementable in a not-too-bad worst-case way on all machines with which
I am familiar, and reasonably consistent with current implementations.

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 don't see how to achieve more transportably; if someone can, good.

I find this enough to be useful, but only marginally.  It is at least
fairly easy to know what I can count on.  I consider a little bit that
I can count on better than a lot that isn't there when I need it.

			-- David Dyer-Bennet
			-- ...decwrl!dec-rhea!dec-mrvax!ddb