This is the mail archive of the
mailing list for the GCC project.
Re: [3.3] Followup to C++ forced unwinding
-----BEGIN PGP SIGNED MESSAGE-----
Mark Mitchell wrote:
> You still haven't explained what might happen outside the catch-clause
> that cannot happen inside the catch-clause or inside a destructor.
It is unspecified. That's the whole point.
>>I don't see how the latter can be bad. That's what is supposed to
> Whether that is supposed to happen or not depends on whether the user
> wrote "throw;" in the catch-clause. It's perfectly reasonable to fall
> off the end of catch-clauses; that's one way of saying "try this
> operation but keep going if it fails."
Then calling the code in catch() is wrong for cancellation.
> There's no way that we'll ever be able to run code inside a catch clause
> other than "catch (...)"; the exception thrown is not of the right type,
> so there's no way to bind the handler parameter. Therefore, I think
> that if we're going to unwind the stack, it makes sense to skip over
> catch-clauses, other than "catch (...)" clauses.
This assumes that the cancellation "exception" is not derived from
exception. If this is the general concensus it's perfectly fine with me.
> (It's also vital that cleanups registered with pthread_cleanup_push be
> run in LIFO order with respect to C++ destructors and catch-clauses
> during stack-unwinding. That's easy to do if you're going to unwind the
> stack (by having the object created by pthread_cleanup_push have a
> destructor), but it's not implemented in the version of glibc that comes
> with Red Hat 9.)
No it's not but that doesn't matter. There are other things which
require code to be recompiled to take advantage of the new cancellation.
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----