Re: [Boost-users] [serialization]

From: Daryle Walker (darylew_at_[hidden])
Date: 2005-11-13 06:19:04

[Sorry for the late response.]

BTW, please put in an actual subject relating your specific concern.  All I
see in my e-mail client are our tags.

On 11/9/05 1:02 PM, "Paul Giaccone" <paulg_at_[hidden]> wrote:

> I am serialising data structures that include objects of the form:
> 
>   std::vector<boost::shared_ptr<MyClass> >
> 
> where MyClass contains simple times and further classes.
> 
> This would not deserialise correctly in Boost 1.33.0 when in XML format,
> and I think there was discussion of there being a bug in deserialisation
> of vectors in that version of the serialization library.
> 
> The bug persisted with the new version of Boost (not 1.33.1 that has
> just been released but a version from the CVS from a few days ago, which
> is probably close to or the same as 1.33.1 anyway).
> 
> I tracked it down to the serialisation of an uninitialised boolean, to
> which Visual Studio .NET 7.1 had given the garbage value 205.  The
> serialization library generates a stream error when this is read back
> into a boolean, naturally enough, because it is not a valid value for a
> boolean.

Is this uninitialized Boolean part of Boost's serialization code, or is it
part of your class (called "MyClass" here)?  The person responsible for this
bug is the one who owns the code at fault.

Did you check if MyClass's serialization works on a single object?  Did you
check if serialization works on non-XML archives, both single objects and
your special vector?

> My question is whether the serialization library should be made more
> robust to handle uninitialised variables.  In the case of all other
> variables, of course, it is not easy or not possible to detect in a
> simple manner whether or not a variable is initialised: is that integer
> meant to have value 1.23456E+66 or is it just uninitialised?  For
> booleans, though, a value of other than 0 or 1 means it has not been
> initialised, and perhaps this should throw an exception on writing to
> the archive rather than on reading from it.

Reading an uninitialized variable that isn't an "unsigned char" (or an array
of such) is undefined behavior, no matter what.  Such readings can (and have
on some platforms) cause a trap/crash.  It is not the responsibility of the
serialization routines to muddle through uninitialized variables.  It's
impossible anyway:

1.  How is the serialization code supposed to know if the variable is
uninitialized?  If your code has a flag indicating whether or not the
variable is initialized, just redirect your efforts into making the variable
always initialized (and remove the flag)!

2.  Even if detection was possible, what policy were you going to have if an
uninitialized value was found?  And how would you enforce it?

3.  And how do you know that a "1.23456E+66" integer value is illegal value?
By reading it (and causing the problems in [1])?  What about values of "0"
or "1" from a Boolean?  You made really big and really bad assumption there;
the truth is that the bit-level format of a "bool" object is COMPLETELY
UNSPECIFIED!  It doesn't have to use an no-set-bits pattern for False or a
simple single-set-bit (or all-set-bits) pattern for True.  One or both of
the two valid states could have multiple bit patterns allowed.

3a. In fact, I made a shocking realization researching for this thread.  The
standard describes "bool" in section 3.9.1, paragraph 6.  Unlike "wchar_t"
(described in paragraph 5), the "bool" does not have to be a rip-off of
another built-in integral type!  It can a distinct integral type from
"char," "short," "int," or "long."  Or it doesn't have to be a true integral
type at all; it could just ACT like one when focused through the compiler!
(Is this realization a bug?  Should I report it on "comp.std.c++"?)

4.  If you're using some sort of (discrimated) union, where only some of the
members are valid at any time, then you must serialize only the currently
active ones.  It is IRRESPONSIBLE for you to do otherwise!

> If handling uninitialised variables is not practical, then perhaps there
> could be a warning in the documentation that uninitialised booleans will
> cause stream errors on deserialisation.

Such handling isn't just impractical, it's impossible.  It can NEVER be used
as a legitimate programming technique.  Why should we waste text describing
any/every potential illegal program?  It's also _not_ a problem specific to
serialization; it's a general programming restriction that all of us should
know already.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com