Boost logo

Boost :

Subject: Re: [boost] [test] Re: Conflicts when building libraries at root
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-03-09 18:39:06


On Tuesday 10 March 2015 11:25:30 Gavin Lambert wrote:
> On 10/03/2015 10:34, Vladimir Prus wrote:
> > On 03/09/2015 02:24 PM, Andrey Semashev wrote:
> >> On Monday 09 March 2015 23:15:16 Peter Dimov wrote:
> >>> Jürgen Hunold wrote:
> >>>> Am Montag, 9. März 2015, 13:14:48 schrieb Vladimir Prus:
> >>>>> This [asynch-exceptions on] does not seem like a feature we can
> >>>>>
> >>>>> globally set?
> >>>>
> >>>> Perhaps we can, but I'm not an expert in vc exception handling...
> >>>
> >>> No, I very much would not like everything to be built with
> >>> asynch-exceptions on.
> >>
> >> +1, SEH should be done explicitly where required and not mixed up with
> >> C++ exceptions.
> >
> > So why is Boost.Test enabling those? Are there any particular files in
> > Boost.Test that need it?
>
> I haven't looked at the code, but I suspect it is so that it can
> intercept such faults (eg. null pointer dereferences) and translate them
> into test failures.
>
> _set_se_translator can be used to automatically convert SEH exceptions
> into a specific C++ exception (which is better than using catch(...)),
> but /EHa must be enabled on the code where the exception is thrown in
> order to get an accurate location.

I can see some explicit SEH in execution_monitor, and a cursory look through
catch(...) didn't reveal places which looked like they're supposed to deal
with structured exceptions. I didn't look deep though.

The option appeared back in 2005 [1], it refers to the minimal Boost.Test.
Currently, minimal.hpp uses execution_monitor to run the tests, so the
compiler option may very well be outdated now. I say we remove it and see what
happens.

[1]
https://github.com/boostorg/test/commit/e7502ce9b9a4fcb789ef8ca05a5dfd87da1d702c


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk