This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [basic-improvements] try/finally support for c/c++ - more tests
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Geoff Keating <geoffk at geoffk dot org>, "zack at codesourcery dot com" <zack at codesourcery dot com>, "jakub at redhat dot com" <jakub at redhat 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>, "jason at redhat dot com" <jason at redhat dot com>
- Date: 08 Nov 2002 04:07:09 -0200
- Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests
- Organization: GCC Team, Red Hat
- References: <133260000.1036714743@warlock.codesourcery.com>
On Nov 7, 2002, Mark Mitchell <mark@codesourcery.com> wrote:
> 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.
I fail to see how longjmp_unwind could possibly be implemented without
EH frame information for all frames, C ones included. I mean, if all
you have is a chain of jmp_bufs that link together some call frames,
but you can't get from them to other call frames that have actual
cleanups, I don't see how longjmp_unwind could get to the cleanups in
order to run them.
But then, this thread was the first time I heard of longjmp_unwind, so
perhaps I'm missing some magic about it. Or it's just that the need
for EH call frames in C for it to work is so obvious that nobody
brought it up, and it was stupid of me to even consider it might not
be the case :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer