Subject: Re: [boost] License of endian and limits in Boost detail
From: John Maddock (boost.regex_at_[hidden])
Date: 2013-03-19 14:04:35
>> * 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
> 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-**
>> # 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
> for Android OS awaiting a response.
No idea, I only know what in:
>> #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 <machine/endian.h>
>> # else
>> # include <sys/endian.h>
>> # 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
CPU's yes, but I believe Win32 on Arm is always LE:
>> * 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
>> * 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
> Not sure why that check is that way. Someone will have to explain further.
The original issue has the explanation:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk