[basic-improvements] try/finally support for c/c++

[Richard Henderson]

On Wed, Nov 06, 2002 at 10:32:15AM -0800, Aldy Hernandez wrote:
> > > + A @code{goto}, @code{break}, @code{return}, or @code{continue}
> > > + statement can be used to transfer control out of a try block but not
> > > + into one.  Also, a longjump may not be used to transfer control into a
> > > + try or finally block.  If done, the behavior is undefined.
> > 
> > @code{longjmp}.  May it be used to jump out of such a block?  All the
> > rules that jumps into try blocks are not permitted (and you'll need to add
> > switch to the statements that might jump into a block) should be listed as
> > constraints (with corresponding testcases for the errors from the
> > constraint violations); although violating them at runtime with GNU C
> > computed gotos would be undefined.  May a finally block be jumped into
> > (and if so, where does execution pass after the finally block is
> > finished)?  May a finally block be jumped out of?
> 
> Richard could you elaborate here?  It was my understanding that
> longjmp may not be used to jump into a try/finally block or out of
> one?  What are the actual restrictions?

Well, longjmp pretty much bypasses all the logic one would care to
ask about.  I would say that such would have to be undefined.  There
is mention in the IA-64 psABI docs of a separate longjmp_unwind
function that _is_ EH aware, but that's the exception not the rule.
So leaving a try block via longjmp is going to have to be undefined.

I don't see how one could enter a try block via longjmp.

Something I just thought of here is GCC's computed goto extension.
I don't know if the middle-end cleanup code handles this properly.
We should have a test in the testsuite for this.


r~