[boost] Fwd: [serialization] test_demo_portable_archive failures

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-06-08 16:59:59

Sorry, these should have been CC'ed to this list earlier (two messages
inline below):

---------- Forwarded message ----------
From: Caleb Epstein <caleb.epstein_at_[hidden]>
Date: Jun 8, 2005 5:48 PM
Subject: [serialization] test_demo_portable_archive failures
To: Running Boost regression tests <boost-testing_at_[hidden]>,
Beman Dawes <bdawes_at_[hidden]>

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_at_[hidden]> 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