Boris Gubenko wrote:
I've got some additional comments about the endian'ness of HP-UX -- see attached. To our slight embarrassment, while HP-UX/ia64 does predefine _BIG_ENDIAN macro, our other big-endian platform -- PA-RISC -- does not. However, the proposed fallback strategy is guaranteed to generate the correct result for a platform where neither _BIG_ENDIAN nor _LITTLE_ENDIAN macro is defined.
If people think, that this is a good idea to check _BIG_ENDIAN/ _LITTLE_ENDIAN macro first and, then, fall back to OS/architecture check, I can submit an obvious, trivial patch for endian.hpp.
To me, the crux of the matter is that while little-endian HP-UX/ia64 is a remote possibility, it is not completely impossible. And if this creature ever comes to existence, it will define _LITTLE_ENDIAN macro, so the endian'ness check will continue to work.
"
A compile time check is adequate.
True, but the proper way to check at compile time is to test for one of the _BIG_ENDIAN or _LITTLE_ENDIAN macros. I believe most or all of the big-endian Unix platforms define _BIG_ENDIAN = 1, but few of the little-endian platforms define _LITTLE_ENDIAN. So I'd suggest checking for one of the two macros, and then, only if neither of them is set, fall back to checking the OS and architecture.
By the way, while unlikely, a little-endian HP-UX ABI on Integrity isn't completely out of the question at some point in the future. We already have the ability to compile little-endian code with our HP-UX compiler, and the _BIG_ENDIAN macro is the way to tell which option was used. "
I think the file <endian.hpp> needs to be refactored. It is turning into a mess. We need to make it clearer that it is a decision tree: 1. Is it GCC? Use header <endian.h> 2. If not, does the processor have a unique endianness? 3. If not, does the OS / processor combo have a unique endianness? 4. If not, are any macros such as _LITTLE_ENDIAN defined. But in the meantime, why not add the patch. --Johan