FYI, John Maddock has just added the tests to trunk/libs/config that I wrote for a new defect macro: BOOST_NO_COMPLETE_VALUE_INITIALIZATION https://svn.boost.org/trac/boost/changeset/61153 And some documentation: https://svn.boost.org/trac/boost/changeset/61154 A test failure indicates that the specific compiler doesn't have completely implemented value-initialization. In the coming few days, the test is likely to cause regression failures, because I still need to define the defect macro for those specific compilers (at boost/config/compiler). Although I already expect certain compilers to fail (MSVC <= 2010, CodeGear/Borland <= 2010, GCC < 4.4, and various versions of Sun) I chose not to define the defect macro /beforehand/, because the test output provides some extra information about the particular compiler issue. Moreover, once the defect macro is defined, the test framework no longer indicates whether the compiler defect is really there. I'll keep an eye on the regression page, http://www.boost.org/development/tests/trunk/developer/config_.html and fix them one by one, but please don't hesitate to remind me if there's a regression failure regarding the new defect macro that I overlooked. The defect macro will allow fixing ticket #3869, "Unconditional call to memset in value_initialized()", reported by Aleksey Gurtovoy: https://svn.boost.org/trac/boost/ticket/3869 by adding an #ifdef to utility/value_init.hpp: #ifdef BOOST_NO_COMPLETE_VALUE_INITIALIZATION std::memset(&x, 0, sizeof(x)); #endif Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center