EH clobbered by longjmp again

[Joe Buck]

Jim Wilson writes:

> int
> main()
> {
>   int i = 10;
>   try
>     {
>       if (g)
> 	i = 11;
>       else
> 	i = 12;
>       throw i;
>     }
>   catch (int j)
>     {
>       printf ("i = %d\n", i);
>       printf ("j = %d\n", j);
>       exit (0);
>     }
>   return 0;
> }
> 
> If we use exact ISO C setjmp/longjmp semantics for the try/throw, then
> the variable `i' as used in the catch clause has an indeterminate value, for
> exactly the same reasons as it does in the above example.  This is why gcc
> gives a warning for it.
>
> What does C++ say about this case?  Does `i' have a well defined value in
> the catch clause, and if so, which value is it?  I need to know the answer
> to this question in order to decide how to fix the problem.

The draft standard does not address this case specifically, but it does
not assume any connection at all between exceptions and setjmp/longjmp,
and in fact most vendors are using explicit stack-unwinding techniques.
In the absence of any specific language permitting the clobbering of
automatic variables, I think we have to assume they cannot be clobbered;
the exception is just a non-local goto with stack unwinding.  So it is
as if we had written (I assume g is global bool or int?)

int
main()
{
   int i = 10;
     {
       if (g)
 	i = 11;
       else
 	i = 12;
       goto _catch;
     }
   _catch:
   int j = i;
     {
       printf ("i = %d\n", i);
       printf ("j = %d\n", j);
       exit (0);
     }
   return 0;
}

i and j must be the same always, because throwing i and catching as j
is specified in the standard to mean that j is a copy of i.

So, since the standard says nothing about any connection between
setjmp/longjmp and exceptions, if we want to use setjmp/longjmp we must
hide the fact (possibly forcing a spill of i to memory in this case).