David Raulo wrote:
Hi, 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've suppressed this.
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.
unfortunately this would break binary archives created by versions 1.42 and 1.43. I've looked more carefully into this: I've discovered the class_id_type has the same problem. So current trunk version is passing all the tests I expect it to pass. That leaves the problem of reading version 6 binary archives of which there are two types. I made the 1.44 library version 8. That leaves version 7 available for the "mis-labeled" binary archives. I've included in example a program called fix_six. This program will change the library version # from 6 to 7. So if one has a problem with a version 6 binary archive, it should be addressable by running fix_six <filename>. Then everything should be fine.
So, what can I do to help?
I'd appreciate it if you or any one else want's to try the trunk and the fix_six program to verify that this actually addresses the issue and actually makes these broken archives readable. One could also verify that no information is lost when reading back the version #. That is, internal to the library, the version has been left at int32 so that it can be detected as originally written. Robert Ramey