Re: Unusual program termination and exception handling
On 15 Jun, 13:18, Daniel Krugler <daniel.krueg...@googlemail.com>
wrote:
My interpretation is, that the
exit of the handler does actually happen, when bullet three
of the list is evaluated:
"Finally, control is returned to the host environment [..]"
but not before. This again means that the two first bullets
describing the effects of exit(0) should happen in the context
of an unfinished exception handler (15.1 [except.throw]/7), which
means that the evaluation of the throw expressions without
operands will just reactivate the exception as described in
15.1 [except.throw]/6.
So, the caller of std::exit shall hold the control because other
behavior is not explicitly permitted, right?
Does this answer your question?
Almost :-)
Example 2:
#include <cstdlib>
#include <exception>
#include <iostream>
struct X
{
~X()
{
std::cout << (int)std::uncaught_exception() << std::endl;
}
} x;
struct Y
{
~Y()
{
std::exit(0);
}
};
void on_terminate()
{
std::cout << "on_terminate()" << std::endl;
std::abort();
}
int main()
{
std::set_terminate(on_terminate);
try
{
Y y;
throw 0;
}
catch (int) {}
}
Isn't the behavior of this program undefined? Must
std::uncaught_exception() return true? Note: GNU C++ calls
std::terminate.
Which version of GNU C++ are you referring to?
I tried mingw32-g++ ver. 4.5.0 (with -std=c++0x option) and mingw32-g+
+ ver. 3.4.5.
Do you have some specific wording in your mind, that should
lead to this conclusion of causing UB or calling terminate?
No. But I might overlook something.
Example 3:
#include <cstdlib>
#include <exception>
#include <iostream>
struct X
{
~X()
{
std::cout << "~X()" << std::endl;
}
} x;
void on_terminate()
{
std::exit(0);
}
int main()
{
std::set_terminate(on_terminate);
throw;
}
Isn't the behavior of this program undefined? According to 18.8.3.1,
"A terminate_handler shall terminate execution of the program without
returning to the caller." A terminate handler that calls std::exit can
eventually terminate execution of the program without returning to the
caller. It seems that the requirement is satisfied in this case.
I don't see why this program should possibly invoke undefined
behaviour.
If a terminate handler does not satisfy the required behavior as
described in 18.8.3.1, the behavior of the program that calls such a
handler is undefined, right? Is the requirement satisfied in the given
example? In general, std::exit can call a function that executes an
infinite loop (the regular program termination is impossible in such
case).
There is also old question asked in the following thread
http://groups.google.com/group/comp.lang.c++.moderated/msg/e30b3f1a8b1c4d09
According to your interpretation of N3092 - 5.3.5/7, the first delete-
expression in the example below shall call the deallocation function.
#include <cstdlib>
#include <iostream>
struct X
{
void operator delete(void *p)
{
std::cout << "X::operator delete" << std::endl;
::operator delete(p);
}
~X()
{
throw 0;
}
};
struct Y
{
void operator delete(void *p)
{
std::cout << "Y::operator delete" << std::endl;
::operator delete(p);
}
~Y()
{
std::abort();
}
};
int main()
{
try
{
delete new X; // (1)
}
catch (int) {}
delete new Y; // (2)
}
Must the second delete-expression call the deallocation function?
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]