setjmp/longjmp

[Blair P. Houghton]

In article <13.UUL1.3#5077 at aussie.UUCP> rex at aussie.UUCP (Rex Jaeschke) writes:
>Let me see if I can shed some light with an example. The following is 
>taken verbatim from my latest book "Portability and the C Language" 
>published by Hayden last October. Its, in the setjmp/longjmp chapter 
>page 254.

Well plugged! :-)

>setjmp return = 0
>j = 10, k = 100
>setjmp return = 1
>j = 20, k = 100
>
>The first time through, j and k have the expected
>values.  However, although both are incremented before test is
>called, when longjmp returns control to setjmp, only j's
>value is still intact.  The value of k was restored to its
>initial value 100 rather than to 120.  For this implementation, it
>appears the register variable is not preserved, while the auto
>is, assuming, of course, the register variable actually is stored in a
>register.  It could well be the opposite way around [[ or both or 
>neither could be presevred.]]  In any case,
>the result is undefined, and therefore unreliable, as we have
>demonstrated.

The Umax C compiler says:

setjmp return = 0
j = 10, k = 100
setjmp return = 1
j = 10, k = 100

And the Umax manual page for setjmp says:

    SETJMP(3)

    NAME
       setjmp, longjmp - non-local goto
    ...
    All accessible 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).^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So, as you say, it seems that the unreliability of setjmp wrt automatic
variables (registers not included ??) is definitely undefined, but not
entirely broken for all compilers.

However, and as usual, despite the evident "correctness" of the Umax C
compiler, its behavior in this case does not prove the code to be
portable.

				--Blair
				  "Some things you just have to *know*..."