Re: [boost] [serialization] automation of class version sanity checking

Subject: Re: [boost] [serialization] automation of class version sanity checking
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-03-04 12:34:35

A worthy idea.  I would have to think about it some more though.  Why not 
re-submit this as a TRAK item.

Robert Ramey

troy d. straszheim wrote:
> Hey (Robert),
>
> Use case.  It is possible (and does happen) that a user tries to
> deserialize version N+1 of a class C with software that only
> understands versions up to N.  What typically happens is that C
> appears to deserialize OK, but it has eaten too many (or few) bytes from 
> the
> archive.   This means that the next class that gets loaded from the
> archive will fail in some unpredictable way.
>
> To deal with this we've started adding the following to all of our
> classes:
> struct C
> {
>   double x;  // this was present in version 0
>   double y;  // this arrived with version 1
>
>   template <typename Archive>
>   void
>   serialize(Archive& ar, const unsigned int version);
> };
>
> BOOST_CLASS_VERSION(C, 1);
>
>
> template <typename Archive>
> void
> C::serialize(Archive& ar, const unsigned int version)
> {
>   if (version > 1)
>     throw unsupported_version(version, 1);
>
>   if (version == 0)
>     ar & x;
>   if (version == 1)
>     ar & y;
> }
>
> ( Note the two arguments to unsupported_version ).
>
> This has the pleasant side effect of often catching errors in *other*
> classes.  Eg if I'm trying to deserialize C and that exception is
> thrown, you can generate a message "trying to read version 3243856293
> of class C, but I only know about version 0-1".   Now I know that
> something has gone quite wrong, for instance someone has removed a member 
> from
> my enclosing class without correctly incrementing and handling the
> version there, and what I've been given as 'version' is garbage.  If
> the message is instead "trying to read version 4 of class C but I only 
> know about
> versions 0-3", it looks like I simply need to update my software,
> nothing more sinister.  This greatly simplifies these situations,
> which otherwise could spiral into a long, painful back-and-forth over
> a segfault in a serialization routine involving questions about what
> software the user has, where the data came from, what software was
> used to write it, etc.
>
> So:
> 1.  I can't think of a situation where having file_version greater
>  than BOOST_CLASS_VERSION isn't a catastrophic error.
>
> 1a.  It'd be nice to configurably auto-check for this kind of
> versioning error.
>
> 2.  As far as I can tell, these checks could be done cleanly inside
> the library, in serialize_adl() (?).
>
> 3.  We don't actually use that unsupported_version exception, which
> takes no arguments and is thrown from serialization of variant  (I
> wrote that and now find it confusing).  I think the variant error should 
> be
> specific to variant (or just totally generic), and unsupported_version
> should be used for the case currently under consideration... and to
> enable the 'pleasant side effect' above, I think the exception should
> carry the greatest version known to the code and the attempted-to-read
> version.
>
> Sanity check please, say so if you want me to try implementing...
>
> -t
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost