Hi, Le 13 juil. 2010 à 14:03, David Raulo a écrit :
Le 12 juil. 2010 à 22:43, Robert Ramey a écrit :
David Raulo wrote:
Here you can see that the original version 20090123 got truncated to 36107 == 20090123 & 65535. This in itself might be a bug, I'm not sure.
I can't see this. But I do see how this assertion would be tripped. If you comment out this assertion does this make it work?
Then the execution proceeds without exceptions, my serialize() method is called, but I verified that it receives 36107 as the version instead of 20090123.
So, what can I do to help? In my view there are 2 problems: - since boost 1.42, the version numbers are internally truncated to 16 bits when reading archives; this causes data loss, which the user might be able to work around in some cases. - since boost 1.43, reading these archives will raise an assertion (iserializer.hpp:173) before the user get any chance to work around the truncated version numbers. I addressed the 2d problem in the atttached patch. Comments welcome. For the first problem, I believe the only solution is to change the definition of version_type in basic_archive.hpp back to uint_least32_t. This would fix a data-loss regression, without any downside that I can think of. Please note that your wish to prevent any new version number bigger than 255 would still be enforced by the static_assert in serialization/version.hpp you introduced with boost 1.43. Is that acceptable? Thanks for your help. David.