setjmp/longjmp

[Fuat C. Baran]

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.  After the longjmp back it would come back to the code
that checked the flag (expecting it to now be false), and skip the
call to the function that longjmps.  (This is a simplified description
of what is going on, but essentially it wants to call the function
only once).  This works under Ultrix 2.0, SunOS 4.x, etc. but fails on
the Encore.  The flag always is true and the function doing the
longjmp is called repeatedly.  After running this through gdb and
watching the flag getting mysteriously corrupted we read the UMAX man
page for longjmp and found the following paragraph:

   Longjmp restores the environment saved by the last call of setjmp.  It
   then returns in such a way that execution continues as if the setjmp
   call had just returned the value val to the function that invoked
   setjmp.  The function that invoked setjmp must not have returned in the
   interim.  Longjmp cannot cause setjmp to return a value of 0. If longjmp
]  is invoked with 0 as the second argument, setjmp returns 1.  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).

I don't know much about the Draft ANSI C, so I was wondering if
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.

Advance thanks for your help.

						--Fuat
-- 
INTERNET: fuat at columbia.edu          U.S. MAIL: Columbia University
BITNET:   fuat at 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