Re: [boost] [Serialization] Bizarre bug

Subject: Re: [boost] [Serialization] Bizarre bug
From: Jarl Lindrud (jarl.lindrud_at_[hidden])
Date: 2009-08-08 03:50:12

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

> 
> 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.
> 

But it is actually meaning, not implementation... Depending on the contents of 
the entire program, the archives will have one binary format or another, and 
will either be readable by other pre-existing programs, or not. That's really 
part of the specification of "ar << t" , not the implementation.

> >
> > 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.

Sure. But this is IMO a much more serious manifestation of the same issue, and 
worries me a lot more. :)

> 
> > 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".
> 

But perhaps I do want tracking turned on, in certain situations, and turned off 
in other situations. What's important is that I know for sure, for any given 
serialization operation, what the tracking setting actually is, and that it 
doesn't change implicitly later on, when somebody adds seemingly innocent code 
to the program.

> > 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.

<somewhat OT>

It could be made simpler than that - the traits would have a default compile-
time setting, and then users could override those settings through a runtime 
call. They would presumably do that at program startup (if at all), and then 
they would still have the option of adjusting the traits again, for any 
particular serialization operation, if and when its needed.

If they want the default compile-time traits, they wouldn't have to do anything.

I do think the whole traits issue needs to be dealt with at runtime. What if I 
need to read archives produced by another program, which in an older release 
had tracking disabled, and then in a later release had it enabled. If the 
tracking trait is set at compile-time then I will only be able to read one or 
the other.

</somewhat OT>

But getting back to the original problem - really the most important thing here 
is that the default tracking level should be unaffected by compile-time 
instantiation. As long as I know what the default is, and that it won't change 
under my feet, then I would be OK with that.

Would that be feasible to implement?

Anyway, thanks Robert for bearing with me... I know you get a lot of requests 
from a lot of people.

Regards,
Jarl.