
On Tue, Mar 19, 2013 at 1:04 PM, John Maddock
* Issue 6013. Patch for BSD based systems:
#if defined(__NetBSD__) || defined(__FreeBSD__) || \ defined(__OpenBSD__) || (__DragonFly__) # if defined(__OpenBSD__) # include
# else # include # endif OK.. I'll adjust the gnu libc include to add those.
Done. And on Win32 use:
(defined(_WIN32) && defined(__ARM__) && defined(_MSC_VER)) // ARM Windows CE don't define anything reasonably unique, but there are no big-endian Windows versions
Not sure what that means.. Especially in light that current ARM cpus are bi-endian.
CPU's yes, but I believe Win32 on Arm is always LE: https://svn.boost.org/trac/**boost/ticket/7516https://svn.boost.org/trac/boost/ticket/7516
Done. * Issue 2762, check for:
defined(__BIG_ENDIAN__) && !defined(__LITTLE_ENDIAN__) -> BE defined(__LITTLE_ENDIAN__) && !defined(__BIG_ENDIAN__) -> LE
Those are some weird looking checks :-\
Indeed, I think you may have added them though https://svn.boost.org/trac/ **boost/changeset/62252 https://svn.boost.org/trac/boost/changeset/62252?
Done. * Issue 1922: Checking for defined(_BIG_ENDIAN) should be
defined(_BIG_ENDIAN) && !defined(_LITTLE_ENDIAN), similarly for
defined(_LITTLE_ENDIAN)
Not sure why that check is that way. Someone will have to explain further.
The original issue has the explanation: https://svn.boost.org/trac/** boost/ticket/1922 https://svn.boost.org/trac/boost/ticket/1922
After thinking about that I realized that this is not a problem with the
new code as it relies on the _BYTE_ORDER comparison only.
I've also added a compatibility header