Re: [Boost-users] [boost.serialization] serialization crash

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-10-26 13:02:17

You guys are barking up the wrong tree.

This behavior is handled by the stream implementation NOT
the serialization library itself.

It is exactly the same case as for floats.  In this case, floats
which are NaN can be written to a stream but not read back.

Same for bools.

There has been work in trying to make a portable implementation
of stream input/output of varying types of NaN's.  This has been
hampered by the fact that the handling of NaN's varies accross
implementation so it doesn't seem possible to make "transportable"
archives which can be guarenteed to recover the same type of
NaN that has been saved.

For what it's worth, my personal view is that the attempt to
save an undefined value - be it a NaN, undefined bool or whatever
should be considered an error and trapped as soon as possible.
Implementing this would be fairly easy with a custom stream
facet which can be optionally attached to any stream.  This would
leave the choice as to what behavior he desires in the hands of the user.

But no one has been motivated to actually do this so far.

Robert Ramey

Deane Yang wrote:
> RIVASSEAU Jean Noel wrote:
>> I've had the same problems. The problem is with the bool field. Code
>> restoring the archive crashes if the bool stored in the archive is
>> not equal to 0 or 1. But since you did not write a constructor in
>> the Obj class, the boolean will actually be initialized with
>> anything( eg, read 14675002 for example), and will be serialized
>> that way in the archive since it seems the serialization code does
>> not check if the bool is equal  to 0 or 1 (only the restoration
>> code).
>>
>> So, the solution is to initialize your boolean correctly and be very
>> careful whenever you use booleans. However, I think the Serialization
>> code should be fixed (remove the check for 0  or 1, it probably does
>> more bad than good.
>>
>
> In my (very) humble opinion, it should be at least symmetric. So
> either no check for 0 or 1 in both directions or a check for 0 or 1
> in both directions.
>
> But it should also be consistent with other built-in types. Since it
> appears that there is no check (is one even possible?) for
>   uninitialized data with other built-in types, I also vote for no
> check.