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. " And more of the discussion: "
The real question is: is little-endian HP-UX ABI on Integrity more than just an academic exercise? How can such code operate on a big-endian OS?
Maybe not today, but who knows tomorrow? As I said, it may be unlikely, but not so much so to completely ignore the possibility. Checking for the appropriate macros first means the code won't have to be changed if and when that possibility ever becomes reality. The endianness is selected in the user mask portion of the PSR, so it's completely under the application's control. We run Linux executables today on HP-UX simply by having a layer that does the endian switch at the system call boundary. " ----- Original Message ----- From: "Johan Råde" <rade@maths.lth.se> To: <boost@lists.boost.org> Sent: Tuesday, October 17, 2006 11:43 AM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
Boris Gubenko wrote:
Boris Gubenko wrote:
I'm checking with the OS folks and will report back here, for both HP-UX/ia64 and Tru64 Alpha.
And the answer is:
You are correct that both platforms are capable of executing in either endianness. However, the operating systems operate in only one. HP-UX is *always* big endian Tru64 is *always* little endian [...] Summary: A compile time check is adequate.
So, with current <endian.hpp>, I think, that we are all set for these platforms.
Thanks, Boris
Excellent. Thanks for the help.
--Johan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost