Opened 12 years ago
Closed 12 years ago
#4929 closed Patches (fixed)
Another serialization version compatibility issue with binary archives
Reported by: | Owned by: | Robert Ramey | |
---|---|---|---|
Milestone: | To Be Determined | Component: | serialization |
Version: | Boost 1.45.0 | Severity: | Problem |
Keywords: | version compatibility | Cc: |
Description
Although the 1-byte / 2-byte library version bug has been resolved (Ticket #4660), I've ran into several other problems of the same kind.
I have an archive created with boost 1.43 which can't load in 1.45. The first problem occurs while loading the first object's preamble - load_preamble() reads tracking level (as one byte) and a version (as 2 bytes, but within the file it is stored as one byte too). The difference is caused by load_override() function for version_type which used char type in 1.43, now it loads as uint_least16_t for archive version 7.
When I fixed this the next thing that failed was deserialization of std::list. The load_collection() function loads item version. In 1.43 this was fixed to unsigned int, in the current it is handled by load_override() which for archive version 7 loads this as uint_least16_t, so it leads to another misalignment. After I fixed those the old archive loads well. I've prepared a patch for those, but I think it probably breaks 1.44 archives using the same version 7.
There's another thing that worth mentioning - the boost serialization library can be compiled into a static library. When linking an application with that library, the resulting exe exports many library functions, which is quite undesirable. I think the solution is to remove dllexport declarations when building a static lib, the patch is attached.
Hope this helps.
Attachments (1)
Change History (6)
by , 12 years ago
Attachment: | patches.zip added |
---|
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Well, the problem I mentioned here is with archives made by v1.43, so - according to the SVN comment - it seems not to be relevant for this. BTW the only file updated is oserializer.hpp; haven't you forgotten to commit any changes within the archive input code? :)
follow-up: 4 comment:3 by , 12 years ago
Note that I've updated binary_archive in several places to address this. The changes have been tested by others and are now in the trunk and release.
Robert Ramey
comment:4 by , 12 years ago
Replying to ramey:
Note that I've updated binary_archive in several places to address this. The changes have been tested by others and are now in the trunk and release.
Robert Ramey
Yes, that seems to work smoothly with any problematic archives I have. Great work, thanks.
comment:5 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I've updated the trunk in an attempt to fix this problem. Please check this out and let me know if it addresses the situation.
Robert Ramey