On Jun 14, 2005, at 2:18 PM, Caleb Epstein wrote:

Does anyone object to me adding a new header <boost/endian.hpp> for this purpose? Or perhaps <boost/detail/endian.hpp> as it would be undocumented. This is all that is required to make the gcc-3_4_3-sunos target 100% pass on all tests. It will also fix any other big-endian platform where the Boost.Serialization test_demo_portable_archive{,_dll} is failing (Darwin I think).

I don't know if this qualifies as a "new feature" or not, but I think it would be nice to have, particularly if any networking code gets introduced any time soon.

Smells like a bug fix to me, and it would be great to get the Serialization lib running cleanly on Darwin. Please go ahead, but put it in boost/detail/endian.hpp because it may move. Doug

Here's my proposed <boost/detail/endian.hpp>. I'm just verifying that everything still compiles for me and the appropriate tests now succeed before committing. I copied the endian-detection code from <boost/detail/limits.hpp>, and therefore reproduced the SGI copyright notice. I'm not sure if this endianness detection was part of the original SGI version of that file, but it appears that a number of Boosters have added various CPUs to the list. Not sure if this is the correct copyright to use in this case. I also added the #if defined (__GLIBC__) block at the top. This should aid in ports to any platform where GNU libc is used, but where the CPU is not one of the small set of known types. I took the liberty of adding the macro BOOST_BYTE_ORDER, which is the moral equivalent of __BYTE_ORDER from GNU libc's <endian.h>. Let me know if this namespace pollution is a bad idea and I'll remove it, but I think it is more useful than BOOST_{BIG, LITTLE}_ENDIAN. I won't even begin to try and address Jody's point about runtime endian-switching CPUs. Yikes! /* * Copyright (c) 1997 * Silicon Graphics Computer Systems, Inc. * * Permission to use, copy, modify, distribute and sell this software * and its documentation for any purpose is hereby granted without fee, * provided that the above copyright notice appear in all copies and * that both that copyright notice and this permission notice appear * in supporting documentation. Silicon Graphics makes no * representations about the suitability of this software for any * purpose. It is provided "as is" without express or implied warranty. */ /* * Copyright notice reproduced from <boost/detail/limits.hpp>, from * which this code was originally taken. * * Modified by Caleb Epstein to use <endian.h> with GNU libc and to * defined the BOOST_ENDIAN macro. */ #ifndef BOOST_DETAIL_ENDIAN_HPP #define BOOST_DETAIL_ENDIAN_HPP // GNU libc offers the helpful header <endian.h> which defines // __BYTE_ORDER #if defined (__GLIBC__) # include <endian.h> # if (__BYTE_ORDER == __LITTLE_ENDIAN) # define BOOST_LITTLE_ENDIAN # elif (__BYTE_ORDER == __BIG_ENDIAN) # define BOOST_BIG_ENDIAN # elif (__BYTE_ORDER == __PDP_ENDIAN) # define BOOST_PDP_ENDIAN # else # error Unknown machine endianness detected. # endif # define BOOST_BYTE_ORDER __BYTE_ORDER #elif defined(__sparc) || defined(__sparc__) \ || defined(_POWER) || defined(__powerpc__) \ || defined(__ppc__) || defined(__hppa) \ || defined(_MIPSEB) || defined(_POWER) \ || defined(__s390__) # define BOOST_BIG_ENDIAN # define BOOST_BYTE_ORDER 4321 #elif defined(__i386__) || defined(__alpha__) \ || defined(__ia64) || defined(__ia64__) # define BOOST_LITTLE_ENDIAN # define BOOST_BYTE_ORDER 1234 #else # error The file boost/detail/endian.hpp needs to be set up for your CPU type. #endif #endif -- Caleb Epstein caleb dot epstein at gmail dot com

On Tue, 2005-06-14 at 15:18 -0400, Caleb Epstein wrote:

Lets try this one more time, but I'll rephrase my question.

Does anyone object to me adding a new header <boost/endian.hpp> for this purpose? Or perhaps <boost/detail/endian.hpp> as it would be undocumented. This is all that is required to make the gcc-3_4_3-sunos target 100% pass on all tests. It will also fix any other big-endian platform where the Boost.Serialization test_demo_portable_archive{,_dll} is failing (Darwin I think).

I don't know if this qualifies as a "new feature" or not, but I think it would be nice to have, particularly if any networking code gets introduced any time soon.

I think this would be a very useful addition for networking. Should it go in utility? I'd prefer not to have it in detail. /ikh ======================================================================= This email may contain confidential and privileged information and is intended for the named or authorised recipients only. If you are not the named or authorised recipient of this email, please note that any copying, distribution, disclosure or use of its contents is strictly prohibited. If you have received this email in error please notify the sender immediately and then destroy it. The views expressed in this email are not necessarily those held by VNL, and VNL does not accept any liability for any action taken in reliance on the contents of this message. VNL does not guarantee that the integrity of this email has been maintained, nor that it is free of viruses, interceptions or interference. _______________________________________________________________________ This email has been scanned for all known viruses by the MessageLabs Email Security System. _______________________________________________________________________

Caleb Epstein <caleb.epstein@gmail.com> writes:

On 6/15/05, Iain K. Hanson <iain.hanson@videonetworks.com> wrote:

...

I think this would be a very useful addition for networking. Should it go in utility? I'd prefer not to have it in detail.

I added it to detail, where I think it should stay until 1.33 goes out the door. We can move it someplace more suitable after that.

Does this make sense?

Is it (whatever it is) an implementation detail or just a prerelease feature? If the latter, detail:: is the wrong feature. Maybe prerelease:: ? -- Dave Abrahams Boost Consulting www.boost-consulting.com