Gennadiy Rozental wrote:
Boris Schaeling
writes: Thanks for the pointer. I was hoping for a provided run-time solution, which would have been the best.
Yes, I agree.
If nothing else works, you can reset signal handler yourself inside the test case.
If stuck with a compile-time solution, it would IMHO have been more lenient having to define e.g. BOOST_TEST_HANDLE_NON_ZERO_CHILD_CODE and BOOST_TEST_HANDLE_SIGCHLD rather than having this new behaviour by default. I really can't currently imagine a scenario where I would want this enabled.
Boost.Test is trying to catch all kinds of failures. Child proces crashing or returning non-zero error code is usual indication of an error.
I'm not convinced. As for signalling a crashing child process (if it can be detected) as a fatal error, yes. As for treating a non-zero "error" code from the result of executing a child process as a fatal error, no (IIUC it is not an error code, it is a status/exit code that _could_ indicate an error or simply a non-positive result). As an example, the "ls" program uses a non-zero status code to indicate that the searched for files were not found. Is this a fatal error - I don't think so. It's an analogy to the C++ debate on whether to use status codes vs using exceptions. If you are still not convinced, would it then be possible for you to add a supported mechanism to selectively disable/enable the interpretations of such events as fatal errors or not? BOOST_TEST_CATCH_SYSTEM_ERRORS is just too coarse a mechanism. As a side note: I've been searching the archives for the boost developers/users list and found no posts where the users where complaining about _not_ having SIGCHLD handled. I have though found a couple of ones where people have been complaining about the opposite since the introduction of the feature. Best regards, Johan