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

Subject: Re: [boost] License of endian and limits in Boost detail
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2013-03-19 10:49:45

On Tue, Mar 19, 2013 at 5:25 AM, John Maddock <boost.regex_at_[hidden]>wrote:

> First pass at the Predef header for this at <
>>>>
>>> https://raw.github.com/**grafikrobot/boost-predef/**
>> master/include/boost/predef/**endian.h<https://raw.github.com/grafikrobot/boost-predef/master/include/boost/predef/endian.h>
>> >.
>> Currently only tested on my OSX laptop. Would appreciate others trying it
>> out. The info is a combination of the indispensable description from
>> predef.sf.net (Bjorn Reese et al), known endian specifications I could
>> find
>> on the architectures I currently detect, and a small amount of general web
>> searching.
>>
>
> I haven't looked at your version yet, but here's the start of the
> reverse-engineering info:
>
> Output:
> ~~~~~
>
> * Define BOOST_LITTLE_ENDIAN when little endian.
> * Define BOOST_BIG_ENDIAN when big endian.
>

See my previous post about naming.

> * Define BOOST_PDP_ENDIAN when PDB endian.
>

I avoided using the *PDP* name as there where PDP variants that had
different byte orderings. I used the more accurate
BOOST_ENDIAN_BIG/LITTLE_BYTE/WORD names instead.

> * 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.

> *Define BOOST_BYTE_ORDER to either 1234 (LE) or 4321 (BE).
>

See question about this in other post.

> Post SGI version modifications.
> ~~~~~~~~~~~~~~~~~~~~~
>
> These are all BSL licensed mods, mostly based on bug reports:
>
> *Issue 7703: check for __BIGENDIAN__ and __LITTLEENDIAN__
>

Already in there.

> * 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.

> #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.

> * Select from STLPort options when available (patch for embedded VC++ plus
> STLPort):
> defined(_STLP_BIG_ENDIAN) && !defined(_STLP_LITTLE_ENDIAN) -> BE
> defined(_STLP_LITTLE_ENDIAN) && !defined(_STLP_BIG_ENDIAN) -> LE
>

OK, will add that.

> * Issue 2762, check for:
> defined(__BIG_ENDIAN__) && !defined(__LITTLE_ENDIAN__) -> BE
> defined(__LITTLE_ENDIAN__) && !defined(__BIG_ENDIAN__) -> LE
>

Those are some weird looking checks :-\

> * 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.

> * REv 35591: defined(__ppc__) || defined(__hpux) -> BE
>

I'll have to look at PPC/POWER as current generations are bi-endian. But we
could conditionally make it BE for the older PPCs.

> * Rev 35587: defined(__amd64)  || defined(__amd64__) || defined(_M_AMD64)
> || defined(__x86_64) || defined(__x86_64__) || defined(_M_X64) -> LE
> * Rev 30185: defined(__ia64) || defined(__ia64__) || defined(_M_IX86) ||
> defined(_M_IA64) || defined(_M_ALPHA) -> LE
>

Already done.

> * Finally, Caleb Epstein's original modification:
>
> #if defined (__GLIBC__)
> // GNU libc offers the helpful header <endian.h> which defines
> // __BYTE_ORDER
> # include <endian.h>
>

Already done.

-- 
-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo