Xref: utzoo comp.std.c:1145 comp.sys.encore:229
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!columbia!cunixc!fuat
From: fuat@cunixc.cc.columbia.edu (Fuat C. Baran)
Newsgroups: comp.std.c,comp.sys.encore
Subject: Re: setjmp/longjmp
Message-ID: <1477@cunixc.cc.columbia.edu>
Date: 3 May 89 23:11:14 GMT
References: <1447@cunixc.cc.columbia.edu> <1989Apr27.165319.23986@utzoo.uucp> <10189@smoke.BRL.MIL> <4059@ficc.uu.net>
Reply-To: fuat@cunixc.cc.columbia.edu (Fuat C. Baran)
Organization: Columbia University Center for Computing Activities
Lines: 34

In article <4059@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>I agree with Norman... the dpANS handling of setjmp/longjmp is undesirable.

I encountered this problem on an Encore multimax.  Upon further
reading of the Encore cc(1) man page, we found that if you give it the

	-q nocompiler_registers

option, then automatics do not get moved into registers by the
compiler.  Thus we don't need to changed automatics to statics or
volatiles.

By the way, I looked at a copy of K&R (2nd ed) today (yes, I know,
this is not an ANSI or draft ANSI C reference), and on page 254 it
says:

"longjmp restores the state saved by the most recent call to setjmp,
using the information saved in env, and execution resumes as if the
setjmp function had just executed and returned the non-zero value val.
[...] Accessible objects have the values they had at the time longjmp
was called; values are not saved by setjmp."

						--Fuat

P.S.  What is the current status of ANSI C?  Has it become the
standard yet?  I don't have any recent information on its status.  We
would like to get a copy of the standard once it is official.


-- 
INTERNET: fuat@columbia.edu          U.S. MAIL: Columbia University
BITNET:   fuat@cunixc.cc.columbia.edu           Center for Computing Activities
USENET:   ...!rutgers!columbia!cunixc!fuat      712 Watson Labs, 612 W115th St.
PHONE:    (212) 854-5128                        New York, NY 10025