> On Sep 6, 2016, at 12:39 PM, Richard Smith <[email protected]> wrote:
> On 6 September 2016 at 11:56, John McCall <[email protected]
> <mailto:[email protected]>> wrote:
> > On Sep 6, 2016, at 11:50 AM, Thiago Macieira <[email protected]
> > <mailto:[email protected]>> wrote:
> > Em terça-feira, 6 de setembro de 2016, às 11:38:43 PDT, John McCall
> > escreveu:
> >> This would be inappropriate; the appropriate solution would be to ask the
> >> committee for a new function in namespace std that could be implemented
> >> with abi::__forced_unwind. I believe that's the chief purpose of that
> >> function, to allow that sort of functionality to be implemented in the
> >> future.
> >>
> >> If std::current_exception works, of course, all the better.
> >
> > I will post to std-discussion and see if there's a consensus. I'm not sure
> > there can be because this is outside of the C++ language: there's no such
> > thing as forced unwinds in the standard.
>
> Hmm. I think this used to not be true; there were library features (e.g.
> longjmp)
> that were allowed, but not required, to be implemented by unwinding the stack.
> But now it seems that these places have all been changed to specify undefined
> behavior if they would bypass any non-trivial destructors.
>
> That's true, but it does not place restrictions on intervening 'catch (...)'
> blocks, and (since no exception has been thrown) they presumably must /not/
> be entered. (You don't get UB from a longjmp where a corresponding throw
> would enter a catch(...) block -- although that may just be a wording defect.)
>
> The possibility of forced unwinding invoking a 'catch (...)' block with no
> current exception seems broken to me. For instance, this may or may not call
> terminate() if f() results in a forced unwind, depending on how 'throw;' is
> implemented:
>
> try {
> f();
> } catch (...) {
> log_error(); // might reasonably assert(std::current_exception())
> throw;
> }
>
> Pretending that a forced unwind throws a C++ exception of some known type
> seems likely to be the best approach -- and I'd expect that exception to be
> capturable via std::current_exception and counted by
> std::uncaught_exceptions, or exception-safe code using those facilities will
> not function correctly in the presence of a forced unwind. (And likewise for
> foreign exceptions; we presumably want to pretend that they are just like C++
> exceptions but are of a type that doesn't match that of any handlers.)
I agree that defining a standard "foreign exception" type is probably the best
approach (with, I assume, a minimal set of opaque accessors) unless the
committee wants to take a hard-line stance that code like this should be
written as a destructor.
John.
_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
