Re: [boost] License of endian and limits in Boost detail
Philip Bennefall wrote:
For my project, I am trying to stick exclusively to the Boost Software license. I wanted to use boost/cstdint.hpp, which pulls in a lot of content (boost/config.hpp is the one that includes the most). Among the things it includes I see boost/detail/endian.hpp and boost/detail/limits.hpp.
limits.hpp says: // Copyright 2001 John Maddock // Distributed under the Boost Software License, Version 1.0. (See accompany- // ing file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) /* * Copyright (c) 1997 * Silicon Graphics Computer Systems, Inc. * * Permission to use, copy, modify, distribute and sell this software * and its documentation for any purpose is hereby granted without fee, * provided that the above copyright notice appear in all copies and * that both that copyright notice and this permission notice appear * in supporting documentation. Silicon Graphics makes no * representations about the suitability of this software for any * purpose. It is provided "as is" without express or implied warranty. */ Is John Maddock reading this? What is the story? Clearly it's not possible to take the SGI-licensed code and to re-license it under the Boost licence without either (a) getting permission or (b) knowing that the licences are compatible, which isn't true in this case in this direction. Has this really been broken for 12 years? Phil.
Is John Maddock reading this?
Nod.
What is the story? Clearly it's not possible to take the SGI-licensed code and to re-license it under the Boost licence without either (a) getting permission or (b) knowing that the licences are compatible, which isn't true in this case in this direction.
Has this really been broken for 12 years?
Originally this code (and Boost in general) was not under the BSL, in fact most of it was under an SGI-like license. Unfortunately there were a few corner cases we couldn't easily get rid of. In the case of limits.hpp I'm almost completely sure we can just remove it, I don't think that any system that relied on it could cope with modern Boost anyway. endian.hpp is much harder, Beman what did you borrow from SGI for this one? John.
----- Original Message ----- From: "John Maddock" <boost.regex@virgin.net> To: <boost@lists.boost.org> Sent: Wednesday, March 06, 2013 6:04 PM Subject: Re: [boost] License of endian and limits in Boost detail
Is John Maddock reading this?
Nod.
What is the story? Clearly it's not possible to take the SGI-licensed code and to re-license it under the Boost licence without either (a) getting permission or (b) knowing that the licences are compatible, which isn't true in this case in this direction.
Has this really been broken for 12 years?
Originally this code (and Boost in general) was not under the BSL, in fact most of it was under an SGI-like license. Unfortunately there were a few corner cases we couldn't easily get rid of. In the case of limits.hpp I'm almost completely sure we can just remove it, I don't think that any system that relied on it could cope with modern Boost anyway. endian.hpp is much harder, Beman what did you borrow from SGI for this one? John. Are there any news on what might be done regarding this? I looked a little more into it today, and it appears as though something as trivial as boost/circular_buffer.hpp pulls in the whole config folder with endian.hpp and limits.hpp so I am avoiding using them altogether for now in this project. Kind regards, Philip Bennefall _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Are there any news on what might be done regarding this? I looked a little more into it today, and it appears as though something as trivial as boost/circular_buffer.hpp pulls in the whole config folder with endian.hpp and limits.hpp so I am avoiding using them altogether for now in this project.
I've just removed detail/limits.hpp and edited boost/limits.hpp to not refer to it. We'll see if anyone complains I guess. endian.hpp is harder to know what to do with: there's no actual code in there, it's more like the accumulated wisdom of multiple Boosters plus bug reports etc. I'm actually not sure why SGI's copyright ended up in there: looks like when Caleb Epstein originally wrote that header he borrowed the "wisdom" from limits.hpp and so put SGI's copyright on it. Any ideas on how we would go about creating a clean version? If someone described the logic in words, and someone else wrote a new header from the description would that do it - or am I deceiving myself? Thanks, John.
----- Original Message ----- From: "John Maddock" <boost.regex@virgin.net> To: <boost@lists.boost.org> Sent: Tuesday, March 12, 2013 10:31 AM Subject: Re: [boost] License of endian and limits in Boost detail
Are there any news on what might be done regarding this? I looked a little more into it today, and it appears as though something as trivial as boost/circular_buffer.hpp pulls in the whole config folder with endian.hpp and limits.hpp so I am avoiding using them altogether for now in this project.
I've just removed detail/limits.hpp and edited boost/limits.hpp to not refer to it. We'll see if anyone complains I guess. endian.hpp is harder to know what to do with: there's no actual code in there, it's more like the accumulated wisdom of multiple Boosters plus bug reports etc. I'm actually not sure why SGI's copyright ended up in there: looks like when Caleb Epstein originally wrote that header he borrowed the "wisdom" from limits.hpp and so put SGI's copyright on it. Any ideas on how we would go about creating a clean version? If someone described the logic in words, and someone else wrote a new header from the description would that do it - or am I deceiving myself? Thanks, John. I don't know enough about the subject of detecting endianness to offer a sensible practical suggestion. Is there any official maintainer responsible for endian.hpp? It just seems such a pity to me that a part of Boost that almost every library seems to depend on, has these legal ambiguities. I tried bcp:ing everything from shared_ptr to circular_buffer to cstdint to property_tree, and all of them pull in this particular file (seemingly by depending on boost/config.hpp). Kind regards, Philip Bennefall
On Tue, Mar 12, 2013 at 4:31 AM, John Maddock <boost.regex@virgin.net>wrote:
Are there any news on what might be done regarding this? I looked a little
more into it today, and it appears as though something as trivial as boost/circular_buffer.hpp pulls in the whole config folder with endian.hpp and limits.hpp so I am avoiding using them altogether for now in this project.
I've just removed detail/limits.hpp and edited boost/limits.hpp to not refer to it.
We'll see if anyone complains I guess.
endian.hpp is harder to know what to do with: there's no actual code in there, it's more like the accumulated wisdom of multiple Boosters plus bug reports etc. I'm actually not sure why SGI's copyright ended up in there: looks like when Caleb Epstein originally wrote that header he borrowed the "wisdom" from limits.hpp and so put SGI's copyright on it. Any ideas on how we would go about creating a clean version? If someone described the logic in words, and someone else wrote a new header from the description would that do it - or am I deceiving myself?
If someone describes the general aspects of the detection I can see about adding it to my Predef library. With the eventual expectation that the library is going to make it into Boost soon obviously. But if it doesn't it would be then OK to steal the code into Boost without the library.. I could also do some research into doing the detection entirely on my own. But that would take more time. PS. The Predef library has almost all the changes from the review in it by now (documentation being the largest change left). -- -- -- 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
----- Original Message ----- From: "Rene Rivera" <grafikrobot@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, March 14, 2013 2:45 AM Subject: Re: [boost] License of endian and limits in Boost detail On Tue, Mar 12, 2013 at 4:31 AM, John Maddock <boost.regex@virgin.net>wrote:
Are there any news on what might be done regarding this? I looked a little
more into it today, and it appears as though something as trivial as boost/circular_buffer.hpp pulls in the whole config folder with endian.hpp and limits.hpp so I am avoiding using them altogether for now in this project.
I've just removed detail/limits.hpp and edited boost/limits.hpp to not refer to it.
We'll see if anyone complains I guess.
endian.hpp is harder to know what to do with: there's no actual code in there, it's more like the accumulated wisdom of multiple Boosters plus bug reports etc. I'm actually not sure why SGI's copyright ended up in there: looks like when Caleb Epstein originally wrote that header he borrowed the "wisdom" from limits.hpp and so put SGI's copyright on it. Any ideas on how we would go about creating a clean version? If someone described the logic in words, and someone else wrote a new header from the description would that do it - or am I deceiving myself?
If someone describes the general aspects of the detection I can see about adding it to my Predef library. With the eventual expectation that the library is going to make it into Boost soon obviously. But if it doesn't it would be then OK to steal the code into Boost without the library.. I could also do some research into doing the detection entirely on my own. But that would take more time. Hello, For my part, I would be most greatful to anyone willing to spend the time to correct this problem. For me, it's a bit of a Boost usage showstopper because pretty much every library includes endian.hpp. While my knowledge on the subject of detecting endianness is quite limited, I would be more than happy to do anything I can to help resolve the situation. Kind regards, Philip Bennefall
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Philip Bennefall Sent: Sunday, March 17, 2013 9:31 AM To: boost@lists.boost.org Subject: Re: [boost] License of endian and limits in Boost detail
----- Original Message ----- From: "Rene Rivera" <grafikrobot@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, March 14, 2013 2:45 AM Subject: Re: [boost] License of endian and limits in Boost detail
On Tue, Mar 12, 2013 at 4:31 AM, John Maddock <boost.regex@virgin.net>wrote:
Are there any news on what might be done regarding this? I looked a little
more into it today, and it appears as though something as trivial as boost/circular_buffer.hpp pulls in the whole config folder with endian.hpp and limits.hpp so I am avoiding using them altogether for now in this project.
I've just removed detail/limits.hpp and edited boost/limits.hpp to not refer to it.
We'll see if anyone complains I guess.
endian.hpp is harder to know what to do with: there's no actual code in there, it's more like the accumulated wisdom of multiple Boosters plus bug reports etc. I'm actually not sure why SGI's copyright ended up in there: looks like when Caleb Epstein originally wrote that header he borrowed the "wisdom" from limits.hpp and so put SGI's copyright on it. Any ideas on how we would go about creating a clean version? If someone described the logic in words, and someone else wrote a new header from the description would that do it - or am I deceiving myself? If someone describes the general aspects of the detection I can see about adding it to my Predef library. With the eventual expectation that the library is going to make it into Boost soon obviously. But if it doesn't it would be then OK to steal the code into Boost without the library.. I could also do some research into doing the detection entirely on my own. But that would take more time.
Hello,
For my part, I would be most greatful to anyone willing to spend the time to correct this problem. For me, it's a bit of a Boost usage showstopper because pretty much every library includes endian.hpp. While my knowledge on the subject of detecting endianness is quite limited, I would be more than happy to do anything I can to help resolve the situation.
I agree that getting rid of this 'feature' is an important issue. We really should ensure that Boost licencing 'does what is says on the tin' - being Boost licensed. John's proposal and then add to the proposed Predef library sounds a good way forward. Actually I suspect that there is really only one way to do this task - whatever the actual macro variable names used in the code. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On Mon, Mar 18, 2013 at 9:10 AM, Paul A. Bristow <pbristow@hetp.u-net.com>wrote:
John's proposal and then add to the proposed Predef library sounds a good way forward.
Actually I suspect that there is really only one way to do this task - whatever the actual macro variable names used in the code.
Probably.. FYI.. I worked up an initial implementation in the Predef library over the weekend from the information I could find on-line. Which I suspect is less than what the current endian header has. I'll check it in tonight and ask for feedback as to what's missing and style. -- -- -- 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
On Mon, Mar 18, 2013 at 9:59 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Mon, Mar 18, 2013 at 9:10 AM, Paul A. Bristow <pbristow@hetp.u-net.com>wrote:
John's proposal and then add to the proposed Predef library sounds a good way forward.
Actually I suspect that there is really only one way to do this task - whatever the actual macro variable names used in the code.
Probably.. FYI.. I worked up an initial implementation in the Predef library over the weekend from the information I could find on-line. Which I suspect is less than what the current endian header has. I'll check it in tonight and ask for feedback as to what's missing and style.
First pass at the Predef header for this at < 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. -- -- -- 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
On Tue, Mar 19, 2013 at 8:17 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Mon, Mar 18, 2013 at 9:59 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
First pass at the Predef header for this at < 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.
Am I correct that the public code also includes tests? If so, can it be removed so that it is only compiled and used when testing?
On Tue, Mar 19, 2013 at 1:12 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
On Tue, Mar 19, 2013 at 8:17 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Mon, Mar 18, 2013 at 9:59 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
First pass at the Predef header for this at <
https://raw.github.com/grafikrobot/boost-predef/master/include/boost/predef/...
. 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.
Am I correct that the public code also includes tests? If so, can it be removed so that it is only compiled and used when testing?
The testing header is "empty" when not running tests. So there's nothing to remove. -- -- -- 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
On Mon, 18 Mar 2013, Rene Rivera wrote:
First pass at the Predef header for this at < 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.
If this is supposed to replace detail/endian.hpp, couldn't you define the same macros? BOOST_BIG_ENDIAN or BOOST_LITTLE_ENDIAN, BOOST_BYTE_ORDER which can be 4321 or 1234, etc. Boost refused to document those because they aren't reliable enough, but that doesn't mean users didn't come to rely on them. -- Marc Glisse
On Tue, Mar 19, 2013 at 3:59 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
On Mon, 18 Mar 2013, Rene Rivera wrote:
First pass at the Predef header for this at <
. Currently only tested on my OSX laptop. Would appreciate others trying it out. The info is a combination of the indispensable description from
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> 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.
If this is supposed to replace detail/endian.hpp, couldn't you define the same macros?
The version in Predef is meant to supplant detail/endian.hpp. When it's working we can see about writing a drop-in replacement if needed.
BOOST_BIG_ENDIAN or BOOST_LITTLE_ENDIAN, BOOST_BYTE_ORDER which can be 4321 or 1234, etc.
If you read the documentation for the Predef library you would see that I'm following a particular naming convention that defines categories (BOOST_category_subcat_subsubcat). I do have some questions regarding the BYTE_ORDER macros.. Are the macros defining the 4321/1234 numbers actually needed? Are there situations where the on/off indicator macros aren't enough? Boost refused to document those because they aren't reliable enough, but
that doesn't mean users didn't come to rely on them.
Since the ones in Predef are documented, and assuming Predef was/is accepted, then it would be a matter of search and replace for user code. But I could also add a "compatibility" mode (with a user define to enable it) that defines the old macros. -- -- -- 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
On Tue, Mar 19, 2013 at 6:00 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Mar 19, 2013 at 3:59 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
BOOST_BIG_ENDIAN or BOOST_LITTLE_ENDIAN, BOOST_BYTE_ORDER which can be 4321 or 1234, etc.
If you read the documentation for the Predef library you would see that I'm following a particular naming convention that defines categories (BOOST_category_subcat_subsubcat). I do have some questions regarding the BYTE_ORDER macros..
Are the macros defining the 4321/1234 numbers actually needed? Are there situations where the on/off indicator macros aren't enough?
According to Wikipedia [1], there are cases of mixed endianness, so the BOOST_BYTE_ORDER macro could have e.g. value 3412. Also, FP endianness may differ from the one of integers, so probably there have to be separate sets of macros for these. [1] http://en.wikipedia.org/wiki/Endianness
On Tue, Mar 19, 2013 at 9:26 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
On Tue, Mar 19, 2013 at 6:00 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Mar 19, 2013 at 3:59 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
BOOST_BIG_ENDIAN or BOOST_LITTLE_ENDIAN, BOOST_BYTE_ORDER which can be 4321 or 1234, etc.
If you read the documentation for the Predef library you would see that I'm following a particular naming convention that defines categories (BOOST_category_subcat_subsubcat). I do have some questions regarding the BYTE_ORDER macros..
Are the macros defining the 4321/1234 numbers actually needed? Are there situations where the on/off indicator macros aren't enough?
According to Wikipedia [1], there are cases of mixed endianness, so the BOOST_BYTE_ORDER macro could have e.g. value 3412. Also, FP endianness may differ from the one of integers, so probably there have to be separate sets of macros for these.
That, 3412, would be word-swapped big-endian. And hence already handled by BOOST_ENDIAN_BIG_WORD. And so is 2143 word-swapped little-endian as BOOST_ENDIAN_LITTLE_WORD. Not that anyone is likely to run into those in modern programming ;-) -- -- -- 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
Actually I suspect that there is really only one way to do this task - whatever the actual macro variable names used in the code.
Probably.. FYI.. I worked up an initial implementation in the Predef library over the weekend from the information I could find on-line. Which I suspect is less than what the current endian header has. I'll check it in tonight and ask for feedback as to what's missing and style.
First pass at the Predef header for this at < 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. * Define BOOST_PDP_ENDIAN when PDB endian. * Emit a #error when endianness can't be possitively determined. *Define BOOST_BYTE_ORDER to either 1234 (LE) or 4321 (BE). Post SGI version modifications. ~~~~~~~~~~~~~~~~~~~~~ These are all BSL licensed mods, mostly based on bug reports: *Issue 7703: check for __BIGENDIAN__ and __LITTLEENDIAN__ * Issue 7528: patch for android: #if defined( __ANDROID__ ) // Adroid specific code, see: 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 # 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__ #elif defined( _XBOX ) // // XBox is always big endian?? // # define BOOST_BIG_ENDIAN # define BOOST_BYTE_ORDER 4321 #endif * 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 # if (_BYTE_ORDER == _LITTLE_ENDIAN) # define BOOST_LITTLE_ENDIAN # elif (_BYTE_ORDER == _BIG_ENDIAN) # define BOOST_BIG_ENDIAN # elif (_BYTE_ORDER == _PDP_ENDIAN) # define BOOST_PDP_ENDIAN # else # error Unknown machine endianness detected. # endif # define BOOST_BYTE_ORDER _BYTE_ORDER #endif * Issue 7516: Arm defines __ARMEB__ for big endian and __ARMEL__ for little endian. 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 * 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 * Issue 2762, check for: defined(__BIG_ENDIAN__) && !defined(__LITTLE_ENDIAN__) -> BE defined(__LITTLE_ENDIAN__) && !defined(__BIG_ENDIAN__) -> LE * REv 57048: defined(__hppa) -> BE * Issue 2663: defined(__bfin__) -> LE * Issue 1922: Checking for defined(_BIG_ENDIAN) should be defined(_BIG_ENDIAN) && !defined(_LITTLE_ENDIAN), similarly for defined(_LITTLE_ENDIAN) * REv 35591: defined(__ppc__) || defined(__hpux) -> BE * 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 * Finally, Caleb Epstein's original modification: #if defined (__GLIBC__) // GNU libc offers the helpful header <endian.h> which defines // __BYTE_ORDER # include <endian.h> # if (__BYTE_ORDER == __LITTLE_ENDIAN) # define BOOST_LITTLE_ENDIAN # elif (__BYTE_ORDER == __BIG_ENDIAN) # define BOOST_BIG_ENDIAN # elif (__BYTE_ORDER == __PDP_ENDIAN) # define BOOST_PDP_ENDIAN # else # error Unknown machine endianness detected. # endif # define BOOST_BYTE_ORDER __BYTE_ORDER #endif John.
On Tue, Mar 19, 2013 at 5:25 AM, John Maddock <boost.regex@virgin.net>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
Rene Rivera wrote:
#elif defined( _XBOX ) // // XBox is always big endian??
That might not be true any more as the Xbox CPU is about to change (IIRC).
FWIW I don't think that was ever strictly true. The original Xbox had a little endian Intel Pentium 3. The Xbox 360 was indeed always ran as big endian although: "The Power PC chip that powers the XBox 360 can actually be configured to run in either little or big endian mode; the version in the XBox 360 is big endian." But yes, the rumors are the new Xbox will be an AMD Jaguar-based CPU very similar to the PS4.
* 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.
Added the documentation to the header now. And did some cleanup of the detection.. On Tue, Mar 19, 2013 at 1:04 PM, John Maddock <boost.regex@virgin.net>wrote:
* 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<https://svn.boost.org/trac/boost/ticket/7528>
// Here we can use machine/_types.h, see: // http://stackoverflow.com/****questions/6212951/endianness-****<http://stackoverflow.com/**questions/6212951/endianness-**> of-android-ndk<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<https://svn.boost.org/trac/boost/ticket/7528> and http://stackoverflow.com/**questions/6212951/endianness-**of-android-ndk<http://stackoverflow.com/questions/6212951/endianness-of-android-ndk>
I looked into the endianness on Android in more detail and AFAICT my current implementation should work. In particular: a) there does seem to be an endian.h header that is used because it uses gnu-libc (see < https://android.googlesource.com/platform/prebuilts/ndk/+/9283a93c7b03896d32a8e88c9322c827d4303652%5E1..9283a93c7b03896d32a8e88c9322c827d4303652/> b) the detection it does seems to use the same macros I'm already using for CPUs and bi-endian indication on the CPUs that it deploys on. So, even though I added Android detection to Predef, I'll wait until either I or someone else can test the non-operation on Android. [snip] And I'm still working on the rest, like the BSD headers. -- -- -- 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
----- Original Message ----- From: "Rene Rivera" <grafikrobot@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, March 20, 2013 5:52 AM Subject: Re: [boost] License of endian and limits in Boost detail Added the documentation to the header now. And did some cleanup of the detection.. Hi Rene, For my part, I would just like to thank you for taking on the task of fixing this problem. I hope that your Boost licensed solution can replace detail/endian.hpp as soon as possible so that there are no more licensing ambiguities. Kind regards, Philip Bennefall
On Wed, Mar 20, 2013 at 1:27 PM, Philip Bennefall <philip@blastbay.com> wrote:
----- Original Message ----- From: "Rene Rivera" <grafikrobot@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, March 20, 2013 5:52 AM
Subject: Re: [boost] License of endian and limits in Boost detail
Added the documentation to the header now. And did some cleanup of the detection..
Hi Rene,
For my part, I would just like to thank you for taking on the task of fixing this problem. I hope that your Boost licensed solution can replace detail/endian.hpp as soon as possible so that there are no more licensing ambiguities.
Note that this probably not the only non-BSL part of Boost. Looking at the inspection report and ignoring issues with tests, examples and docs, at least the following files seem to have a different license: boost/program_options/detail/utf8_codecvt_facet.hpp boost/test/utils/runtime/cla/detail/argument_value_usage.hpp boost/shared_container_iterator.hpp There are a few nonessential and deprecated files that don't have a license statement as well.
----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, March 20, 2013 10:54 AM Subject: Re: [boost] License of endian and limits in Boost detail On Wed, Mar 20, 2013 at 1:27 PM, Philip Bennefall <philip@blastbay.com> wrote:
----- Original Message ----- From: "Rene Rivera" <grafikrobot@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, March 20, 2013 5:52 AM
Subject: Re: [boost] License of endian and limits in Boost detail
Added the documentation to the header now. And did some cleanup of the detection..
Hi Rene,
For my part, I would just like to thank you for taking on the task of fixing this problem. I hope that your Boost licensed solution can replace detail/endian.hpp as soon as possible so that there are no more licensing ambiguities.
Note that this probably not the only non-BSL part of Boost. Looking at the inspection report and ignoring issues with tests, examples and docs, at least the following files seem to have a different license: boost/program_options/detail/utf8_codecvt_facet.hpp boost/test/utils/runtime/cla/detail/argument_value_usage.hpp boost/shared_container_iterator.hpp There are a few nonessential and deprecated files that don't have a license statement as well. Hi Andrey, I see that as a problem in itself, but at least based on my initial tests these headers don't seem to be used nearly as often as something like detail/endian.hpp which is included everywhere. Still, I think it would be nice if all of the standard Boost distribution was covered by the BSL so that all of it really does what it says on the packaging in terms of licensing. Kind regards, Philip Bennefall
On Tue, Mar 19, 2013 at 1:04 PM, John Maddock <boost.regex@virgin.net>wrote:
* 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.
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<https://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 <boost/predef/detail/endian_compat.h> which defines the current set of <boost/detail/endian.hpp> macros. For use in the eventual transition to include from the old header, with some form of warning about it being deprecated. I would appreciate if more people test out that the endian, and other detections, are working for them by running "b2 --verbose-test -a" in the test directory. (After appropriate b2 & boost source tree setup). -- -- -- 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
On Tue, Mar 19, 2013 at 1:04 PM, John Maddock <boost.regex@virgin.net>wrote:
* Issue 2663: defined(__bfin__) -> LE
I'l have to look up what that one is.
Found out what that is.. So added Blackfin CPU detection and corresponding endian indication for it. Hence except for Xbox, I think all the current endian detection (and more) is implemented in Predef. -- -- -- 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
Rene Rivera wrote:
On Tue, Mar 19, 2013 at 1:04 PM, John Maddock <boost.regex@virgin.net>wrote:
* Issue 2663: defined(__bfin__) -> LE
I'l have to look up what that one is.
Found out what that is.. So added Blackfin CPU detection and corresponding endian indication for it. Hence except for Xbox, I think all the current endian detection (and more) is implemented in Predef.
I haven't looked so you might already have it. #if defined(__CELLOS_LV2__) identify big-endian PS3 This should handle both Synergistic Processing Unit( __SPU__ ) and Primary Processing Unit ( defined(__PU__) || defined(__PPU__) ) #if defined(R5900) little-endian PS2. #if defined(HOLLYWOOD_REV) || defined(REVOLUTION) big-endian Wii I'm not sure about WiiU. #if defined(_XENON) || (_XBOX_VER == 200) big-endian ppc Xbox360 #else little-endian x86 Xbox although this check won't necessarily hold once the new xbox comes out, IIRC original xbox is just _XBOX_VER < 200 and it's probably safe to assume _XBOX_VER > 200 will be the new xbox and just error out there so someone can set it up correctly when it's released. You can also check defined(_XENON) && defined(_M_PPC) to see if you're building for xbox360.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: Tuesday, March 19, 2013 4:18 AM To: boost@lists.boost.org Subject: Re: [boost] License of endian and limits in Boost detail
On Mon, Mar 18, 2013 at 9:59 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Mon, Mar 18, 2013 at 9:10 AM, Paul A. Bristow <pbristow@hetp.u-net.com>wrote:
John's proposal and then add to the proposed Predef library sounds a good way forward.
Actually I suspect that there is really only one way to do this task - whatever the actual macro variable names used in the code.
Probably.. FYI.. I worked up an initial implementation in the Predef library over the weekend from the information I could find on-line. Which I suspect is less than what the current endian header has. I'll check it in tonight and ask for feedback as to what's missing and style.
First pass at the Predef header for this at < 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.
Looks a good start. Typo in /* GNU libc provides a header defining __BYT_ORDER. */ I think it should contain this reference http://sourceforge.net/p/predef/wiki/Endianness/ - and others to ensure that we can show it is written using publically available info, not the original SGI version - and not reverse-engineered either - the EU caved in to pressure from IBM et al to ban that! Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On Tue, Mar 19, 2013 at 7:01 AM, Paul A. Bristow <pbristow@hetp.u-net.com>wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera First pass at the Predef header for this at <
https://raw.github.com/grafikrobot/boost-predef/master/include/boost/predef/...
. 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.
Looks a good start.
Typo in /* GNU libc provides a header defining __BYT_ORDER. */
Thanks, fixed locally. And a variety of other silly typos. I think it should contain this reference
http://sourceforge.net/p/predef/wiki/Endianness/
- and others to ensure that we can show it is written using publically available info, not the original SGI version - and not reverse-engineered either - the EU caved in to pressure from IBM et al to ban that!
I've added, locally, documentation, which since I wanted feedback sooner rather than later I avoided writing. -- -- -- 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
On Wed, Mar 6, 2013 at 12:04 PM, John Maddock <boost.regex@virgin.net> wrote:
Has this really been broken for 12 years?
Originally this code (and Boost in general) was not under the BSL, in fact most of it was under an SGI-like license. Unfortunately there were a few corner cases we couldn't easily get rid of.
In the case of limits.hpp I'm almost completely sure we can just remove it, I don't think that any system that relied on it could cope with modern Boost anyway.
endian.hpp is much harder, Beman what did you borrow from SGI for this one?
I wasn't involved in the original creation of either limits.hpp or endian.hpp. I'll leave limits.hpp to you, but for endian.hpp I think Boost.Endian should provide that functionality in a Boost license only header. The boost-root/boost/detail/endian.hpp header can be change to forward to the Boost.Endian header, for compatibility, and the SGI copyright can then be eliminated. I'll add that to the do-list. --Beman
participants (9)
-
Andrey Semashev -
Beman Dawes -
John Maddock -
Marc Glisse -
Michael Marcin -
Paul A. Bristow -
Phil Endecott -
Philip Bennefall -
Rene Rivera