Boost C++ Libraries: Ticket #10505: Use gcc/clang built-in endianity macros (too)

Mon, 15 Sep 2014 10:22:23 GMT

I was looking wrong. Apparently it does fall back to those macros, but because the preceding code does not check that the complete suite of macros (not just _BYTE_ORDER, but also _BIG_ENDIAN/_LITTLE_ENDIAN/_PDP_ENDIAN), it is never used.

Mon, 15 Sep 2014 10:26:23 GMT

Ah, and the code using the built-in macros is the same as I had to patch in the earlier versions anyway as it still does not use __BYTE_ORDER__ anyway.

René Rivera — Tue, 30 Dec 2014 05:28:36 GMT

I don't understand what you are saying in the comments. What is the root of the problem? Can you check the current develop branch to see if addresses the issues?

status changed

René Rivera — Tue, 30 Dec 2014 05:28:42 GMT

status new → assigned

status changed; resolution set

René Rivera — Mon, 18 May 2015 15:56:43 GMT

status assigned → closed
resolution → obsolete

Closing for lack of followup.

status changed; resolution deleted

anonymous — Mon, 18 May 2015 20:13:13 GMT

status closed → reopened
resolution obsolete

The current version fixes the part of the problem that the checks on in endian.h lines 72-99 now won't trigger in the errorneous Bionic libc case when _BYTE_ORDER is defined, but _LITTLE_ENDIAN is not.

However, the gcc 4.6 toolchain (which we still need, because binaries built with newer ones don't work on Android < 2.3 and our code otherwise works on 2.1 just fine) does not define __LITTLE_ENDIAN__, so the fallbacks further down on lines 106 and 124 don't trigger on x86 (on arm the __ARMEL__ define is found).

So I would still suggest adding the test for the older gcc macros:

#if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) && \
		defined(__ORDER_LITTLE_ENDIAN__) && defined(__ORDER_PDP_ENDIAN__)
#    if (__BYTE_ORDER == __ORDER_BIG_ENDIAN__)
#        undef BOOST_ENDIAN_BIG_BYTE
#        define BOOST_ENDIAN_BIG_BYTE BOOST_VERSION_NUMBER_AVAILABLE
#    endif
#    if (__BYTE_ORDER == __ORDER_LITTLE_ENDIAN__)
#        undef BOOST_ENDIAN_LITTLE_BYTE
#        define BOOST_ENDIAN_LITTLE_BYTE BOOST_VERSION_NUMBER_AVAILABLE
#    endif
#    if (__BYTE_ORDER == __ORDER_PDP_ENDIAN__)
#        undef BOOST_ENDIAN_LITTLE_WORD
#        define BOOST_ENDIAN_LITTLE_WORD BOOST_VERSION_NUMBER_AVAILABLE
#    endif
#endif

Since things depend on these in the gcc-provided headers, they should be reliable in gcc and clang.

Sorry, I missed the question on new year's eve.

PS: I wanted to make the line references to github, but trac won't accept it.

René Rivera — Thu, 02 Jul 2015 21:27:39 GMT

Replying to anonymous:

The current version fixes the part of the problem that the checks on in endian.h lines 72-99 now won't trigger in the errorneous Bionic libc case when _BYTE_ORDER is defined, but _LITTLE_ENDIAN is not.

However, the gcc 4.6 toolchain (which we still need, because binaries built with newer ones don't work on Android < 2.3 and our code otherwise works on 2.1 just fine) does not define __LITTLE_ENDIAN__, so the fallbacks further down on lines 106 and 124 don't trigger on x86 (on arm the __ARMEL__ define is found).

So I would still suggest adding the test for the older gcc macros:
#if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) && \
		defined(__ORDER_LITTLE_ENDIAN__) && defined(__ORDER_PDP_ENDIAN__)
#    if (__BYTE_ORDER == __ORDER_BIG_ENDIAN__)
#        undef BOOST_ENDIAN_BIG_BYTE
#        define BOOST_ENDIAN_BIG_BYTE BOOST_VERSION_NUMBER_AVAILABLE
#    endif
#    if (__BYTE_ORDER == __ORDER_LITTLE_ENDIAN__)
#        undef BOOST_ENDIAN_LITTLE_BYTE
#        define BOOST_ENDIAN_LITTLE_BYTE BOOST_VERSION_NUMBER_AVAILABLE
#    endif
#    if (__BYTE_ORDER == __ORDER_PDP_ENDIAN__)
#        undef BOOST_ENDIAN_LITTLE_WORD
#        define BOOST_ENDIAN_LITTLE_WORD BOOST_VERSION_NUMBER_AVAILABLE
#    endif
#endif
Since things depend on these in the gcc-provided headers, they should be reliable in gcc and clang.

Sorry, I missed the question on new year's eve.

PS: I wanted to make the line references to github, but trac won't accept it.

I still how your code above works. You are checking for defined(__BYTE_ORDER__). But are actually checking for __BYTE_ORDER equality to the __ORDER_* macros. Is the whole thing supposed to be a third alternative in the GNU libc branch? As in __BYTE_ORDER__ should get used if neither __BYTE_ORDER nor _BYTE_ORDER are defined?

Wed, 15 Jul 2015 17:18:00 GMT

Replying to grafik:

I still how your code above works. You are checking for defined(__BYTE_ORDER__). But are actually checking for __BYTE_ORDER equality to the __ORDER_* macros. Is the whole thing supposed to be a third alternative in the GNU libc branch? As in __BYTE_ORDER__ should get used if neither __BYTE_ORDER nor _BYTE_ORDER are defined?

Yes, exactly, it's a third alternative. It is exactly analogous to the first two, but its advantage is that it is built into (sufficiently recent versions of) the gcc and clang compilers themselves, so it works even on systems that don't define the _BYTE_ORDER and __BYTE_ORDER or don't define them completely as is the case of Android.

James E. King, III — Wed, 04 Oct 2017 03:35:24 GMT

This issue should be resolved or moved into github issues.