Boost logo

Boost :

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

"Martin Wille" <mw8329_at_[hidden]> wrote in message
> Gennadiy Rozental wrote:
>> "Martin Wille" <mw8329_at_[hidden]> wrote in message
>>> 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
> or

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 ;).


Boost list run by bdawes at, gregod at, cpdaniel at, john at