Re: [basic-improvements] try/finally support for c/c++ - more tests

[Mark Mitchell <mark at codesourcery dot com>]

> You mean statically into .gcc_except_table, or dynamically?
> Statically could be doable through some builtin and some hacks,
> dynamically would be way harder.
I meant statically -- a "you have to check to see if I might have
registered anything" bit.

> That's why the proposal is about __try/__finally only, not __except
> where it is e.g. not clear at all what happens if you throw in C++
> and __except control expression returns -1.
> At least from what I read in MSFT docs on the web, their __try/__finally
> matches Aldy's patch.
Except that it also handles asynchronous exceptions, which ours doesn't.
Where we'd get a SIGFPE you get a structured exception in Microsoft's
stuff.

> > I would prefer longjmp_unwind; that's something we're supposed to
> > have anyhow, and it would be very useful in making existing C
> > libraries play more nicely with C++, so implementing that would be
> > a definite win.
> longjmp_unwind would be good to have.
Well, we all seem to agree on that.  So, if we can do it that way,
we get a definitively useful feature required by the ABI, and we
don't open a can of worms on the language side.  If it's really too dang
slow, we can do something different.  On the other hand, you'll have
avoided adding frame information to every C program, which is a big win
on space, and something our C users have told us they don't want in
the past.

And you can avoid the setjmps if you write your code in C++; there
you can use the resource-acquisition-as-initialization idiom.

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com