On Feb 18, 2014, at 8:49 AM, John McCall <[email protected]> wrote:
> On Feb 18, 2014, at 8:02 AM, Marshall Clow <[email protected]> wrote: >> On Feb 17, 2014, at 10:50 AM, John McCall <[email protected]> wrote: >>> On Feb 15, 2014, at 11:05 AM, Marshall Clow <[email protected]> wrote: >>>> Specifically: >>>> libc++ & libc++abi call the terminate handler that was active when the >>>> exception was created. >>>> libstdc++ and libsup++ call the terminate handler that was installed >>>> when the exception was rethrown. >>>> >>>> Does the C++ ABI document have anything to say about terminate handlers >>>> being updated while an exception is in flight? >>> >>> I would expect this to be controlled by the language standard, not by the >>> ABI document. >> >> And yet it is spelled out in the ABI document in section 2.2.2.1: >> (http://mentorembedded.github.io/cxx-abi/abi-eh.html) >> >> • The fields unexpectedHandler and terminateHandler contain pointers to >> the unexpected and terminate handlers at the point where the exception is >> thrown. The ISO C++ Final Draft International Standard [lib.unexpected] >> (18.6.2.4) states that the handlers to be used are those active immediately >> after evaluating the throw argument. If destructors change the active >> handlers during unwinding, the new values are not used until unwinding is >> complete. > > To me, everything after the first sentence here is (1) explanatory and (2) > deferring to the standard. > >>> Amusingly, the current standard is simply ungrammatical: >>> N3797 [terminate]p1: >>> Called by the implementation when exception handling must be abandoned >>> for any of several reasons, in effect immediately after throwing the >>> exception. >>> Clearly what’s “in effect” is supposed to be the terminate_handler, but... >>> >>> As far as I can tell, this is a splice left over from a previous revision. >>> e.g. >>> C++03 [lib.terminate]p1: >>> Effect: Calls the terminate_handler function in effect immediately after >>> evaluating >>> the throw-expression, if called by the implementation, or calls the >>> current >>> terminate_handler function, if called by the program. >>> >>> Both standards are vague about *which* throw-expression is meant when more >>> than one is associated with the same exception object. If you can get the >>> committee to clarify, please ask them to consider what should happen with >>> std::rethrow_exception as well. >> >> This is LWG issue 2088: http://cplusplus.github.io/LWG/lwg-active.html#2088 >> Apparently this was changed right before C++11 was released (see N3242 for >> the actual change), and it is (as you say) confused. >> The editor’s comments in n3242 reflect this confusion. >> >> So, what we have is that C++98/03 specifies things one way, and C++11/14 >> (arguably) a different way. >> And libc++abi implements the C++03 standard, and libsup++ (4.8) implements >> the C++11 standard. > > If the standard is now being changed to always use the current > terminate_handler at the time that the terminate is triggered, then neither > library is implementing it correctly, and in fact these fields in the > exception info are now obsolete. That’s an explicit change in specified > behavior, though, so I’m a little surprised by it. > > The difference as you’ve described it is just that libsupc++ is overwriting > the handler fields on a rethrow (“throw;”), and libc++abi is not. CI 2088 > actually doesn’t identify this as an ambiguity, but it seems to me to be the > only truly unaddressed problem unless they’re really switching the semantics > to always use the current handler. That is exactly the difference that I am describing. And I’d like to see that difference removed (and I don’t really care which way it is resolved). I also agree that it should be decided by the C++ standards group, not the members of this mailing list. But I think that people here should be aware of it. — Marshall
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
