Ambiguity in definition of setjmp/longjmp makes them much less useful

[Larry Campbell]

We have implemented a portable (or so we thought) exception handling
facility for C.  In order to allow exception handlers to have the same scope
as the code being guarded, we used setjmp/longjmp instead of ssignal.
However, the ambiguous definition of setjmp/longjmp is giving us heartburn.

Consider the following code:
----------------------------------------
 1    {
 2    int x;
 3    x = 0;
 4    if (! setjmp(foo))
 5        {
 6        x = 1;
 7        foo();
 8        }
 9    else
10        {
11        printf(x = %d\n", x);
12        }
13    }
----------------------------------------

If foo() calls longjmp, the value of x when line 11 gets executed appears to
be undefined (I don't have a copy of the ANSI standard, but I've checked
about eight compiler manuals; most say it's undefined, or undefined if x
isn't declared volatile).

In the three compilers I've tested that claim ANSI compliance, declaring x to
be volatile yields the desired result (x = 1).  In the non-ANSI compilers,
disabling optimization yields the desired result, but enabling optimization
usually yields x = 0.

I've never seen any value for x other than 0 or 1.

My real question is this:  Why not define the behavior of setjmp/longjmp so
that the values of ALL local variables are defined, whether or not they've
been allocated to registers?  Otherwise, setjmp/longjmp are significantly
less useful.

For what it's worth, it seems to me that the description of setjmp/longjmp in
K&R 2 does imply that x should have the value 1; is this an area of
disagreement between K&R and ANSI?
-- 
Larry Campbell                          The Boston Software Works, Inc.
campbell at redsox.bsw.com                 120 Fulton Street
wjh12!redsox!campbell                   Boston, MA 02109