Sorry, these should have been CC'ed to this list earlier (two messages inline below): ---------- Forwarded message ---------- From: Caleb Epstein <caleb.epstein@gmail.com> Date: Jun 8, 2005 5:48 PM Subject: [serialization] test_demo_portable_archive failures To: Running Boost regression tests <boost-testing@lists.boost.org>, Beman Dawes <bdawes@acm.org> The sole remaining failures for gcc-3_4_3-sunos appear to be the test_demo_portable_archive{,_dll} tests in the serialization library. These tests are failing because the numeric data that is written to the archive is two \x00 bytes for each value, which causes the restored object to contain all zeroes instead of the correct random data, and the comparison operation fails. My first thought was that this was an endian-ness problem, and in the end I was right. There is a block of code in portable_binary_[io]archive.hpp that checks #ifdef BOOST_BIG_ENDIAN. For some reason this macro is *not* being defined for me on SunOS. I can't find anywhere in Boost that it actually *is* defined, except <boost/detail/limits.hpp>, but this header is not included and trying to include it explicitly yields a slew of compiler errors. So I rebuilt the test program, adding -DBOOST_BIG_ENDIAN to the compiler command line. I still get the identical failure and the same \x00 bytes written to the archive. Looking more closely at the code that is doing the byte-swapping, there are three bugs: portable_binary_oarchive::save_impl: * last is initialized to first + size - 1. This should be first + sizeof (l) - 1; * the temporary variable x should be initialized with *last not *first portable_binary_iarchive::load_impl: * the temporary variable x should be initialized with *last not *first I've commited fixes for these to CVS just now, but I'm *not* sure how to best address the BOOST_BIG_ENDIAN issue. Any suggestions there? -- Caleb Epstein caleb dot epstein at gmail dot com ---------- Forwarded message ---------- On 6/8/05, Caleb Epstein <caleb.epstein@gmail.com> wrote:
I've commited fixes for these to CVS just now, but I'm *not* sure how to best address the BOOST_BIG_ENDIAN issue. Any suggestions there?
I think perhaps a new header file, <boost/endian.hpp> makes the most sense here. I don't think the definition of BOOST_BIG_ENDIAN / BOOST_LITTLE_ENDIAN belong in <boost/detail/limits.hpp> This header is not included unless BOOST_NO_LIMITS is defined, which I assume is only for non-standards-conforming implementations. -- Caleb Epstein caleb dot epstein at gmail dot com