Potential endianness detection problem

[miloyip]

Upstream issue https://code.google.com/p/rapidjson/issues/detail?id=100

Currently Endianness is very important in Value because it uses this for aligning 32-bit and 64-bit integer, in order to implement "no overhead integer conversion".

This "optimization" depends on the RAPIDJSON_ENDIAN macro. Currently it has assumes little endian if gcc __BYTE_ORDER__ is not defined. This is error-prone.

Several potential fixes:

1. Better endianness detection with more compilers.
2. If unable to detect, fail to compile and ask user to define the macro explicitly.
3. Automatic validation of endianness in compile-time or run-time.

Shall check how other cross-platform libraries deal with this issue.

[pah]

Boost has an implementation:

• http://www.boost.org/doc/libs/1_42_0/boost/detail/endian.hpp (simple)
• http://www.boost.org/doc/libs/1_55_0b1/boost/predef/other/endian.h
  (more complex, based on "predef" library).

Btw, shouldn't it be __BYTE_ORDER (without trailing underscores)?

[miloyip]

According to https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
__BYTE_ORDER__ is a predefined macro.

Seems __BYTE_ORDER is defined by some endian.h?