David Raulo wrote:
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?
I have been working on this. I thought I had it. I hadn't realized the the issue arose prior to 1.43. I think that you're analysis is correct. I'll take yet another look at this. Thanks for your patience.
Thanks for your help.
David.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users