From: Robert Ramey (ramey_at_[hidden])
Date: 2007-11-02 13:44:54
Well, that makes a lot of sense. But when I build/test with bjam
the tail of bjam.log looks like:
====== BEGIN OUTPUT ======
assertion "result.second" failed: file
_type_info.cpp", line 75
EXIT STATUS: 34304
====== END OUTPUT ======
...updated 32 targets...
Peter Dimov wrote:
> Robert Ramey:
>> I've traced through the code with the gdb and seems to me
>> that when assert is invoked, the program bails more or less
>> immediatly without jumping back to the orginal main or
>> invoking an exception that can be caught. This results
>> in tests which provoke assertions as being marked "passed".
> assert should in principle call abort(), which should return a
> failure exit code to the OS, so the test should fail...
>> Actually, this is unbelievable to me and I have to
>> believe that I'm missing something really dumb. I
>> also took a cursory look at Boost Test code and don't
>> see any special provision made for assert.
>> Also I investigated BOOST_ASSERT. It looks
>> to me that this code is not conditional upon
>> NDEBUG not being defined - that is that the
>> code included by BOOST_ASSERT would
>> still appear in a release build. Again, I can't help but
>> feel that I'm missing something really obvious.
> BOOST_ASSERT works in three modes. By default, it maps to assert, and
> assert does obey NDEBUG. If BOOST_DISABLE_ASSERTS is defined,
> BOOST_ASSERT is compiled out. If BOOST_ENABLE_ASSERT_HANDLER is
> defined, failed asserts call a function that can be supplied by the
> user. So if your code uses BOOST_ASSERT, you can define a custom
> handler in your tests that prints a message and cause the test to
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk