Re: [3.3] Followup to C++ forced unwinding

[Ulrich Drepper <drepper at redhat dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Mitchell wrote:

> I know that POSIX doesn't endorse this particular behavior, and that
> code that relies on it is non-portable -- but so is unwinding the
> stack.  You could even reasonably argue that unwinding the stack is a
> violation of the POSIX standard; it doesn't say that you do that.

You still don't get it.  This is not about violating POSIX or not.  This
is about implementation (not specifications) relying on the program
never to return from the dead.  A very reasonable assumption.  Once
canceled the only way out is to die after all cleanup handlers are
called.  Entire implementations of thread libraries depend on this and
this cannot be changed.


> You've said that falling off the end of a catch clause might cause all
> kinds of bad things to happen, like process crashes.  I'm trying to find
> out why.  And why that isn't a problem in destructors.

And for the third or fourth time: because the state of the thread
changed.  Certain things cannot be done once the state is cancelled.
These are no arbitrary limitations, they arise from actual implementations.

Listing explicitly things which can go wrong is nonsense.  After the
next change to the thread library the results can be different.  That's
the whole point behind calling something unspecified.


> The C++ programming language does not give you the information you want;
> it does not distinguish "catch" indicating "this is where important
> resources are cleaned up" and "catch" indicating "I want to keep going
> if something bad happens."  Sometimes "catch" indicates both of these
> things, or one or the other depending on some condition.

This all the more shows that executing catch() code is inadequate or
even wrong.


> Since the language doesn't tell you that, you have to trust the
> programmer.

Not if the default is to write code which is only causing problems.
Again, in C one has to explicitly violate the rules by adding code.  By
not rethrowing automatically the default code, used in lots of code,
violates the rules.



> It's wrong to try to either skip the clean up or rethrow
> from the end of the clean up; either will drastically change the
> semantics of programs.

The semantics is changed anyway since C++ destructors haven't been
executed so far.  The programs which needed this used the C functions so
far.

- -- 
- --------------.                        ,-.            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)

iD8DBQE+sIqQ2ijCOnn/RHQRAtvMAJ9Ynr1m5nHsfCn02I8hSfsmVUuwuQCeOhGc
DRG/IDe0pWtzcBIJ7nQ9jl4=
=9GKz
-----END PGP SIGNATURE-----