boost serialization 1_46_1 incompatible with prior versions due to backwards comparison

[Phil Hartmann <phil.hartmann82@…>]

Archive's writing class_id_type between 1_41 <and prior> and being read back in 1_46 will fail.

basic_binary_iarchive.hpp line 104 in 1_46 is "if(boost::archive::library_version_type(6) < lvt){"

Or 6 < lvt which is lvt >= 7, and because the if before it is 7 < lvt, its essentially lvt == 7.

So if the version is 7 serialize in a 16 bit integer, else versions 1 through 6 serialize in a 32 bit integer.

The problem here is this is backwards. Version 1-6 are 16 bit, 7 might have been 32bit (because of issues in 1_42/1_43).

The code needs to be swapped (assuming consistency throughout the file is to remain).

tracking_type also appears to have the same issue (although it seems to be ok)

version_type I don't get at all, going back through the basic_binary_iarchive.hpp's I don't see how the code is right at all. Anything less than version 7 should be serializing a 8 bit int from what I can tell.

Prior versions can be viewed at: http://www.boost.org/doc/libs/1_44_0/libs/serialization/src/basic_archive.cpp http://www.boost.org/doc/libs/1_41_0/libs/serialization/src/basic_archive.cpp http://www.boost.org/doc/libs/1_40_0/libs/serialization/src/basic_archive.cpp ...

Library versions can be viewed at: http://www.boost.org/doc/libs/1_44_0/boost/archive/basic_binary_iarchive.hpp http://www.boost.org/doc/libs/1_41_0/boost/archive/basic_binary_iarchive.hpp http://www.boost.org/doc/libs/1_40_0/boost/archive/basic_binary_iarchive.hpp ...

Side Note: IMHO writing code such as 6 < lvt is extremely unintuitive and backwards of how most people think.

[Phil Hartmann <phil.hartmann82@…>]

Sorry, I had cleaned this up a bit but copied the wrong version in here, was the 5th time submitting this ticket because it kept being rejected as spam.

The versions/library versions are backwards. And on tracking_type I meant 'it seems to work for some cases, but is still inverse of what it should be'

[monsta@…]

The code looks the same in 1.47, so I guess it hasn't been fixed yet. One of my projects is using 1.41 (historical reasons, you know...) and looks like it's still too early to upgrade.

Maybe a big fat warning (with links to all the major bugs like ​this one) should be added to the release notes...

[Phil Hartmann <phil.hartmann82@…>]

monsta,

I created a patch for 1.46_1 in hopes to get it into 1.47 but I got it pretty late in the game. The patch here seems pretty stable, if your feeling adventurous maybe you can try the patch and see if it works and add to the thread. Or let me know if there are more issues that it doesnt fix.

​https://svn.boost.org/trac/boost/ticket/5579

[gtsml.owevwr@…]

Phil,

FYI, I tried your patch on 1.48 and this is working: I can load both binary generated by 1.39 and 1.48.

Frank

[anonymous]

why this patch is still not accepted? is the library unmaintained? should we elect a new maintainer?