> > >
> > > This test is expected to fail (it tests how Boost.Test handles
> > > division by zero)
> > > and if it's not this is an error. That's all.FWIW I'm not a fan of this
> test. >  xlC/PPC hardware does not trap on div.  We can fix it easy
> by adding an
> option > to generate a trap and did so in Boost 1.34.1 but never bothered for
> the Boost > development line.
>
> Not sure I follow this comment. You changed compiler only for boost 1.34.1? Or
> you changed toolset? Why not generate this trap always?
>
> That said, division by zero is just another error condition
> Boost.Test is trying
> to catch and properly report. If you opt not to generate it, you can
> always mark
> this test as intentionally failing.
>
This testcase appears to assume that all hardware will generate an exception on a divide by zero.  I believe that the PPC hardware itself does not raise an exception on a divide by zero.  The compiler can insert special code around the divide by zero to cause an exception similar to what is expected by this testcase but that is not the default of the hardware or the compiler.

In a patch that we provided for Boost 1.34.1 we added an option (-qflttrap=zerodivide) to the Jamfile that would generate the behaviour expected by this testcase.  However, the change was never propagated to the Boost development line which is why the test still fails for us.  Certainly, the test could be marked as a known failure but the underlying assumption of the test that all hardware/software will fail on a divide by zero is false.

The comment was nothing more than a comment about the test itself which has underlying assumptions that are invalid on certain platforms.

Chris Cambly
XL C++ Compiler Development