Well, its definately a mistake. But I'm wondering if the real solution is to left fill the value when loading with 0xff ? Think about this. This would: a) leave current archives working. b) keep portable binary archives as small as possible Robert Ramey Stefan van den Oord wrote:
Hi,
According to the boost web site, this mailing list is the preferred way to report bugs, so I subscribed and send you this:
I believe the example /boost/libs/serialization/example/portable_binary_oarchive.hpp doesn't work correctly. On my platform, Mac OS X, the endian conversion is performed. For a small negative number (say -42l), the endian conversion results in a big negative number (-687865857). The size, however, is computed _before_ the endian conversion, so it is 1 (one) in this case, which is not high enough to hold the converted long.
I guess the solution is to do the endian conversion first, then the size computation. That seems to work for me. Based on the 1_33_1 sources, my version of save_impl is now:
void save_impl(long l){ // we choose to use litle endian #ifdef BOOST_BIG_ENDIAN char * first = static_cast<char *>(static_cast<void *>(& l)); char * last = first + sizeof(l) - 1; for(;first < last;++first, --last) { char x = *last; *last = *first; *first = x; } #endif
long ll = l; char size = 0; do{ ll >>= 8; ++size; }while(ll != -1 && ll != 0); os.put(size);
save_binary(& l, size); }
I hope this helps in improving the example.
Regards,
Stefan van den Oord _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost