Re: [boost] [Serialization] Bizarre bug

Subject: Re: [boost] [Serialization] Bizarre bug
From: Jarl Lindrud (jarl.lindrud_at_[hidden])
Date: 2009-08-07 10:23:18

Robert Ramey <ramey <at> rrsd.com> writes:

> 
> I'm still intrigued as to how such a situation could come up where
> something is saved through a pointer but in another program it isn't.
> I looked at the above link and didn't find this.  Basically, my view
> is that anyone tripped up by this error can't be writing anything
> that makes sense anyway.  I'm looking for a counter example to
> this.
> 
> Robert Ramey
> 

I don't know this arose originally - there may well have been a situation where 
the vector<char> was serialized through a pointer in one program, and 
deserialized as a value, in another program. That is indeed an error, although 
in this case it does not seem that any exception was thrown to signify the 
error (the vector just silently failed to deserialize properly).

On a more fundamental level, I don't understand how this code can *ever* fail:

(1)
    std::ostringstream ostr;
    boost::archive::text_oarchive(ostr) & v0;

    std::istringstream istr(ostr.str());
    boost::archive::text_iarchive(istr) & v1;
    
    bool ok = (v0 == v1);

Here the vector is serialized and deserialized as a value. How is it that 
"tracking" or "implementation" settings for a particular type can be affected 
by the mere presence of this code 

(2)
    ar << pVec; // pVec is a vector<char> *

, or this code

(3)
    ar >> pVec; // pVec is a vector<char> *

, in a completely different part of the program?

Snippet (2), if it appears in a program without snippet (3) also occurring, 
makes the program incorrect, if I understand you correctly. But how is it that 
its mere compile-time presence causes the technically correct code in (1) to 
fail?

And even if snippet (3) is also present somewhere in the program, thus making 
the program correct in your view, IIUC the archives produced in (1) will then 
have a different format than those produced, when snippets (2) and (3) were 
absent. That would imply that archive formats can change silently, through mere 
addition of source code, anywhere else in the program. And the format change 
wouldn't be noticed until some *other* program tries to read the archives and 
fails to do so. Have I understood that correctly?

Regards,
Jarl.