This is the mail archive of the
mailing list for the GCC project.
Re: [basic-improvements] try/finally support for c/c++ - more tests
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Richard Henderson <rth at redhat dot com>, Geoff Keating <geoffk at geoffk dot org>, "zack at codesourcery dot com" <zack at codesourcery dot com>, "aldyh at redhat dot com" <aldyh at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 07 Nov 2002 17:55:21 -0800
- Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests
--On Thursday, November 07, 2002 08:52:37 PM -0500 Jason Merrill
On Thu, 07 Nov 2002 17:26:38 -0800, Mark Mitchell <firstname.lastname@example.org>
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
That has nothing to do with the semantics of try/finally, which just deals
with cleaning up after whatever exceptions do happen to be thrown.
This horse is pretty dang dead, but the point is that people will *expect*
that the construct behaves the same way as Microsoft's "structured
exception handling" stuff -- in every way. Part of that is handling
SIGFPE type events.
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com