Re: [boost] [Serialization] Bizarre bug

Subject: Re: [boost] [Serialization] Bizarre bug
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-08-08 00:29:47

Jarl Lindrud wrote:
> Robert Ramey <ramey <at> rrsd.com> writes:
> Hmmm. This implies that the meaning of the code "ar << t" , depends
> on the content of the entire program.

I would agree that the implementation of ar << t depends upon the
content of the entire program.

>> Note that this has the counter ituitive effect of seeming to "look
>> ahead" in the code.
>
> What's worse is that it also seems to "look across" :)
>
>> Just remember this:  If each load must use the exact same type
>> as each corresponding save.
>>
>> If you follow this rule, you will never have a problem of this
>> nature.

> Let me sum up what it is that worries me. Say I have program A, with
> this kind of code:
>
>    std::ostringstream ostr;
>    boost::archive::text_oarchive(ostr) & v0;
>
>    std::istringstream istr(ostr.str());
>    boost::archive::text_iarchive(istr) & v1;
>
>    bool ok = (v0 == v1);
>
> , and nothing else. Say that I also have another program B, with the
> same kind of code, that reads archives produced by program A.
>
> Everthing is working well. And then in program A, at a later stage,
> some more code is added, containing these lines:
>
> ar << pVec; // pVec is a vector<char> *
>
> , and
>
> ar >> pVec; // pVec is a vector<char> *

> Perhaps the code is not even executed. Now, program A still
> functions. It can read the archives that it has produced *but* the
> archives now, IIUC, have a different format. So when program B tries
> to read the archives, it will fail, and may well fail silently.

True.  But note that this is not the case which brought up the discussion.

> So essentially addition or modification of code, *anywhere* in
> program A, and regardless of whether it is executed, can cause a
> runtime failure in program B! You can imagine how difficult this
> would be to debug.

Default tracking is "track_selectively" and default implementation
level is "? - include class information in the archive.  You might
want to change the implementation level for your classes to "track_always".

> Wouldn't it be easier if serialization settings like tracking_level
> were set by the user, explicitly at runtime? That way one could set
> it exactly as one wants it, rather than having to guess at the side
> effects of compile-time instantiations throughout the entire program.

Actually, I see a lot of merit in this argument. In fact the whole
concept of "serialization_traits" is amounts to a global table
keyed on data type.  So it does have the same problem - ie side
effects that any global table does.  It's not as bad a normal
because it doesn't change dynamically but it can still be a
problem.  On the other hand, having to explicitly specify
these traits for each invocation of ar << ? and ar >> ?
would be very tedious and I dare say unpopular. And likely
prone to other kinds of errors.

You might make a more convincing case that tracking
traits should not include "track_selectively".  Or maybe
the ALL types should have their class information
stored in the archive.  I'm sure that many people would
then complain about efficiency.

It would be possible for someone who had nothing else
to do to re-implement and enhance the Archive templates
with a policy to explicitly use a specific tracking or
implemention level regardless of the "traits setting".
I've actually considered using such a method to
suppress All tracking for the whole archive.  This
would permit using the serialization system for things
Error logging, transacction processing, etc.  Note that
doing this would not require changing any of the
archive or serialization concepts so it would be
applicable "for free" to an program which already
had serialization implemented.

Serialization turns out to be a far richer subject
than first meets the eye.

Robert Ramey

> Regards,
> Jarl.
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost