Re: [boost] [filesystem][program_options][serialization][test] from comp.lang.c++.moderated

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-05-11 17:39:45

"Martin Wille" <mw8329_at_[hidden]> wrote in message 
news:44608D80.2060508_at_yahoo.com.au...
> Gennadiy Rozental wrote:
>> "Martin Wille" <mw8329_at_[hidden]> wrote in message
>> news:44603D05.5080401_at_yahoo.com.au...
>>> Wil Evers wrote:
>>>
>>>> 4) test (please don't get me started)
>>>>
>>>> for any reasonable degree of portability (takes over main(), maps OS
>>>> signals to C++ exceptions, continues to run after failing assert()s,
>>>> etc.)
>>> FWIW, I don't use Boost.Test for the same reasons.
>>
>> Could you be more elebotate? Cause none of the above seems fair. I dont 
>> know
>> about any portability issues related to main in static library (and it's
>> optional nowdays anyway). SIGNAL catching is optional and doesn't 
>> constitute
>> portabiltiy issues per se, whether to use it's up to you.
>>
>
>
> At least for a long time, the signal catching apparently was the default
> behaviour of Boost.Test. The signal handling is broken because it
> exploits undefined behaviour. It caused troubles for several of the
> tests in Boost.
>
> See http://lists.boost.org/Archives/boost/2004/07/67298.php
> or http://lists.boost.org/Archives/boost/2003/10/55496.php

I familiar with there issues and potential UB. But Boost.Test provides both 
alternatives, so you couldn't say that it is broken. Every user is free to 
make a choice either catch system signals but be exposed to potential UB or 
don't and lost reporting in case of crash. As for which alternative is 
selected as a default here my view on this is:
1. In my experience catching signals did not cause any deadlocks in 99% of 
cases. IMO proper reporting prevail.
2. Opting to ignore system signals will cause halt for regression testing in 
some cases (unless we change the setup explicitly)
3. This default was selected from the very beginning. I would be wary to 
change it (the same as changing an interface IMO)
4. I suspect that selecting other alternative would cause more unhappy users 
than this one (someone is always unhappy - the fact of life ;).

Gennadiy