Re: [boost] [serialization] Reading newer archives - wasthrowing unsupported_class_version, now crashes

Subject: Re: [boost] [serialization] Reading newer archives - wasthrowing unsupported_class_version, now crashes
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-05-11 13:32:54

Lars Viklund wrote:
> On Thu, May 10, 2012 at 10:06:42PM -0800, Robert Ramey wrote:
>> Nikolay Mladenov wrote:
>> As to why it's this way, the answer is pretty simple.  The original
>> version of the library has some errors.  Problem is, fixing them
>> is much harder than with other libraries because of the requirement
>> to maintain the ability to read archives created with previous
>> versions.
>
> This is not an answer.

lol - I believe that the question was why this is the way it is.  This
is the simple answer.

> Why was this code defined out, and what is
> solved by doing so?

If I recall correctly, the problem arose when a user started overload
the version number which with other data - some sort of guid or date
or something like that.  The version number was defined as an integer
(or maybe short integer) which these days in C++ is large enough
to hold this kind of data.  When made a change in the library to
enforce catch more user errors, this problem came up.  So I commented
out the change.  I believe that is how we got here today.  (I could
be wrong about this as I'm speaking from memory).  So the current
complaint is that the current library doesn't detect a particular type
of user error which in principle it can but in practice never has.  I could
just change the 0 to 1 to re-enable the code but of course I'll then
risk the ire of someone who has overloaded the version data type.

> What _is_ the underlying problem, there is nothing in your message
> that explains why this happens.

The real underlying problem is the usage in C++ of int or short int as
a datatype.  I've come to believe that should never be done and is
always a potential bug. I've resolved to avoid doing this in the future.
In fact - this problem arose because of an attempt to improve the
code by implementing this policy.

>No-one goes around and disables code
> blocks for no reason, removing functionality.

lol - I had a reason.

> I cannot trust a library that has secret known bugs, especially if it
> has a track record of messing up (like the forgotten version bump and
> all that).

lol - if anyone thinks they can do a better job - feel free to step up!

Robert Ramey