Re: [boost] License of endian and limits in Boost detail

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 
> 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-ndk<http://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 <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
> 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.