https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90682
Bug ID: 90682
Summary: std::terminate() will happily call a null terminate
handler
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include <exception>
int main()
{
std::set_terminate(nullptr);
std::terminate();
}
$ ./a.out
Segmentation fault (core dumped)
In C++98 this program had undefined behaviour, because set_terminate require a
non-null pointer argument. That was relaxed by
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.htm to make it
unspecified:
- Relax the current strong invariants of the set_unexpected and set_terminate
functions - the handler is never a null pointer value. This reduces
requirements on the implementor to define a non-null default handler. The
suggested wording does make the effects of setting a null pointer handler
unspecified, though.
I think we should treat a null handler as equivalent to abort, e.g.
--- a/libstdc++-v3/libsupc++/eh_terminate.cc
+++ b/libstdc++-v3/libsupc++/eh_terminate.cc
@@ -44,7 +44,8 @@ __cxxabiv1::__terminate (std::terminate_handler handler)
throw ()
{
__try
{
- handler ();
+ if (handler)
+ handler ();
std::abort ();
}
__catch(...)
