Re: [boost] [test] Re: Conflicts when building libraries at root

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