Xref: utzoo comp.std.c:1090 comp.sys.encore:221
Path: utzoo!attcan!uunet!lll-winken!ames!ncar!tank!eecae!cps3xx!rang
From: rang@cpsin3.cps.msu.edu (Anton Rang)
Newsgroups: comp.std.c,comp.sys.encore
Subject: Re: setjmp/longjmp
Message-ID: <2760@cps3xx.UUCP>
Date: 27 Apr 89 20:23:30 GMT
References: <1447@cunixc.cc.columbia.edu>
Sender: usenet@cps3xx.UUCP
Reply-To: rang@cpswh.cps.msu.edu (Anton Rang)
Organization: Michigan State University, Computer Science Dept.
Lines: 26
In-reply-to: fuat@cunixc.cc.columbia.edu's message of 27 Apr 89 03:42:32 GMT

In article <1447@cunixc.cc.columbia.edu> fuat@cunixc.cc.columbia.edu (Fuat C. Baran) writes:

   We just got an Encore Multimax running UMAX 4.2 (equivalent to BSD
   4.2).  While bringing up one of our software packages we ran into a
   strange problem with setjmp/longjmp.  The code is setting a flag
   (declared int in main()) and then doing a setjmp.  It would then check
   this flag and if true, set the flag to false and call a function which
   would longjmp.

      [ story about it not working and searching the manual ]
								 All acces-
   ]  sible data have values as of the time longjmp was called except for
   ]  objects of automatic storage class that have been changed between the
   ]  setjmp and longjmp calls.  The values of these objects is indeterminate
   ]  (this behavior conforms to the Draft ANSI C language standard).

This happens with automatic variables which are allocated in registers.  The
setjmp/longjmp code may not save and restore these registers; in this case,
their values will be lost.  In some compilers, you can use 'volatile' to
avoid this; otherwise, declaring variables as 'static' may help (or making 
them 'static volatile' maybe?).

+---------------------------+------------------------+---------------------+
| Anton Rang (grad student) | "VMS Forever!"         | rec.music.newage is |
| Michigan State University | rang@cpswh.cps.msu.edu | under discussion... |
+---------------------------+------------------------+---------------------+