* Emit a #error when endianness can't be possitively determined.
Hm, the Predef library goes to some length to avoid generating errors favoring to be strictly informative. Especially important in the endian case since a good number of current architectures are bi-endian. So I would hate to introduce such an #error. Since as a user I would prefer to fallback on runtime endian determination if the compile time one failed.
OK that may work, I guess where folks need a compile time determination, they can simply check whether one of the options they support is defined or not and issue the #error themselves. In fact for libs like multiprecision which only use endianness as an optimisation, this is actually better ;)
* Issue 7528: patch for android:
#if defined( __ANDROID__ ) // Adroid specific code, see: https://svn.boost.org/trac/** boost/ticket/7528 https://svn.boost.org/trac/boost/ticket/7528 // Here we can use machine/_types.h, see: // http://stackoverflow.com/**questions/6212951/endianness-** of-android-ndkhttp://stackoverflow.com/questions/6212951/endianness-of-android-ndk # include "machine/_types.h" # ifdef __ARMEB__ # define BOOST_BIG_ENDIAN # define BOOST_BYTE_ORDER 4321 # else # define BOOST_LITTLE_ENDIAN # define BOOST_BYTE_ORDER 1234 # endif // __ARMEB__
I already use __ARMEB/L__. Do we know if including the machine/_types.h header is required to get those on Android... Regardless I'll add detection for Android OS awaiting a response.
No idea, I only know what in: https://svn.boost.org/trac/boost/ticket/7528 and http://stackoverflow.com/questions/6212951/endianness-of-android-ndk
#elif defined( _XBOX ) // // XBox is always big endian??
That might not be true any more as the Xbox CPU is about to change (IIRC).
* 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.
* Issue 7516: Arm defines __ARMEB__ for big endian and __ARMEL__ for little endian.
Already 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/7516
* 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 ?
* REv 57048: defined(__hppa) -> BE
That, and a bunch of other PARisk variants already taken care of.
* Issue 2663: defined(__bfin__) -> LE
I'l have to look up what that one is.
* 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 HTH, John.