Re: [Boost-bugs] [Boost C++ Libraries] #1849: Deserialization of std::string overwrites non-copied contents.

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #1849: Deserialization of std::string overwrites non-copied contents.
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2008-06-09 21:35:34

#1849: Deserialization of std::string overwrites non-copied contents.
-------------------------------------------------------------+--------------
  Reporter:  Siegfried Kettlitz <dev_at_[hidden]>  |       Owner:  ramey        
      Type:  Bugs                                            |      Status:  assigned     
 Milestone:  Boost 1.35.1                                    |   Component:  serialization
   Version:  Boost 1.35.0                                    |    Severity:  Showstopper  
Resolution:                                                  |    Keywords:               
-------------------------------------------------------------+--------------
Comment (by anonymous):

 No, there was no exception thrown or anything.

 It must have to do something with the way the deserialization writes into
 that string.

 If the lengths match, it doesn't allocate new memory and also doesn't
 check if the memory referred to belongs to another object and should be
 copied on write.

 Also because the original string was a const, the constness must have been
 cast away somewhere.

 I don't understand this with the actual implementation because of that in
 string.hpp:
 {{{
 ...
 BOOST_CLASS_IMPLEMENTATION(std::string,
 boost::serialization::primitive_type)
 #ifndef BOOST_NO_STD_WSTRING
 BOOST_CLASS_IMPLEMENTATION(std::wstring,
 boost::serialization::primitive_type)
 #endif

 // left over from a previous incarnation - strings are now always
 primitive types
 #if 0
 ... old implementation
 }}}

 as far as i came in the code, the old implementation does the reasonable
 thing (call .clear(), .reserve() and .push_back()).

 But i don't understand where the loading with the new implementation is
 actually happening.

 What does that "primitive_type" mean when loading an object? Maybe a
 string sometimes ain't as primitive as expected.

 The obvious fix would be to use the old implementation again, but i don't
 know if that raises other problems.


 Maybe the problem is in the gnu-stl, maybe someone else can reconfirm it
 with other compilers/platforms because i only have access to the gnu
 compilers and the error occurs on linux and mingw. But let alone that it
 happens on multiple versions of gnu there should be great interest of this
 bug to go away.

-- 
Ticket URL: <http://svn.boost.org/trac/boost/ticket/1849#comment:5>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.