Re: [boost] [utility] value_init workaround fixed [Re: value_init_test failure]

From: David Abrahams (dave_at_[hidden])
Date: 2007-12-09 21:15:59

on Sun Dec 09 2007, Niels Dekker - mail address until 2008-12-31 <nd_mail_address_valid_until_2008-12-31-AT-xs4all.nl> wrote:

> David Abrahams wrote:
>> https://boost-consulting.com/trac/projects/boost/build/trunk reveals
>> that
>> https://boost-consulting.com/trac/projects/boost/changeset/41919
>> introduced a failing test of the utility library.
>
> Thanks for reminding me, Dave.  The test failure actually indicates that
> the MSVC-workaround of value_initialized that I committed a while ago to
> the trunk has a bug: when a value_initialized<T> object is copied, the
> wrapped T object isn't copied properly.  If T has an accessible copy
> constructor, it should be called when copy-constructing a
> value_initialized<T>.  And if T has an accessible copy assignment
> operator, it should be called when assigning a value_initialized<T>.   I
> have just committed a fix for this bug to the trunk: 
> http://svn.boost.org/trac/boost/changeset/41942

Unfortunately, as
https://boost-consulting.com/trac/projects/boost/build/trunk shows,
that appears to have broken Boost.Python on Linux/GCC.

> Luckily the bug wasn't yet released!  I mean, it isn't yet in Boost
> release version 1.34.1, and I hope we can take it out of the release
> branch.
>
> The commit (changeset [41942]) aims to fix some other issues as well. 
> Fernando Cacciola (the owner of value_init) and I also decided to no
> longer distinguish between a "workaround version" and a non-workaround
> version of value_initialized<T>.  
>
> Until now the workaround was only for MSVC.  But it has appeared
> that various other compilers have value-initialization related
> issues:
>
> GCC Bug 30111 - Value-initialization of POD base class doesn't
> initialize members
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111
> GCC Bug 33916 - Default constructor fails to initialize array members
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33916
> Borland Report 51854 - Value-initialization: POD struct should be
> zero-initialized
> http://qc.codegear.com/wc/qcmain.aspx?d=51854
>
> I recently added tests on these issues to value_init_test, and they
> caused a test failures on a majority of the test platforms, at
> http://beta.boost.org/development/tests/trunk/developer/utility_.html

I guess maybe that explains the Boost.Python test failures?

> In general, those compilers that don't support value-initialization well
> forget to zero-initialize the POD-members of a type T, in some cases... 
> The workaround is basically as follows:  The constructor of
> value_initialized<T> stores the bytes of an instance of T in an
> aligned_storage::type object, whose bytes are set to zero, followed by a
> placement new.
>
> Hopefully the new value_init.hpp will make an end to the test failures. 
> If so, I hope we can still merge the trunk version with the release
> version, 1.35.0.    

I'm sure that once we get things stabilized we'll have no problem
getting it into the release branch.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com