Boris Gubenko wrote:
Will submit a patch later today.
Attached the patch. Tested on: HP-UX/ia64 and PA-RISC with aCC and gcc Tru64 Alpha with cxx and gcc Linux/ia64 with icc and gcc Index: endian.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/detail/endian.hpp,v retrieving revision 1.4 diff -r1.4 endian.hpp 39a40,45
#elif defined(_BIG_ENDIAN) # define BOOST_BIG_ENDIAN # define BOOST_BYTE_ORDER 4321 #elif defined(_LITTLE_ENDIAN) # define BOOST_LITTLE_ENDIAN # define BOOST_BYTE_ORDER 1234
----- Original Message ----- From: "Boris Gubenko" <Boris.Gubenko@hp.com> To: <boost@lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko@hp.com> Sent: Thursday, October 19, 2006 8:56 AM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc Johan Rede wrote:
But in the meantime, why not add the patch.
Will submit a patch later today. Boris ----- Original Message ----- From: "Johan Råde" <rade@maths.lth.se> To: <boost@lists.boost.org> Sent: Thursday, October 19, 2006 8:35 AM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost