Xref: utzoo comp.std.c:1158 comp.sys.encore:234
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!pyramid!prls!philabs!linus!alliant!jeff
From: jeff@Alliant.COM (Jeff Collins)
Newsgroups: comp.std.c,comp.sys.encore
Subject: Re: setjmp/longjmp
Keywords: setjmp, longjmp
Message-ID: <3126@alliant.Alliant.COM>
Date: 4 May 89 14:56:23 GMT
References: <1447@cunixc.cc.columbia.edu>
Reply-To: jeff@alliant.Alliant.COM (Jeff Collins)
Organization: Technology Partners, Inc.
Lines: 22

In article <1447@cunixc.cc.columbia.edu> fuat@cunixc.cc.columbia.edu (Fuat C. Baran) writes:
>someone could explain the idea behind the behaviour we are
>experiencing on the Encore (i.e. why can't automatic variables be
>modified after the setjmp such that they retain their value after the
>longjmp back)?  I looked at the man pages for a couple of compilers
>that sort of are "Draft ANSI"ish and this point is in general not
>explained clearly.
>

	When the setjmp is first invoked, the current register state is saved,
	in the jmpbuf array.  This register state includes the current values
	of automatic variables.  When the subsequent longjmp is called, the
	state restored in the jmpbuf array is restored, including the register
	set.  This means that any changes to automatic variables after the
	setjmp are "overwritten", because the register that stores the 
	variable is restored to its value before the setjmp.  There is no way
	that setjmp/longjmp can handle this problem, as they do not know which
	automatic variable are "going to possibly change sometime in the future.

	The rule when dealing with setjmp/longjmp and an optimizing compiler
	(ie. one that makes heavy use of registers, like Encore's), is to 
	force the variable in question to not be in a register.