Boost logo

Boost :

From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2006-10-19 15:44:59

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
> #elif defined(_BIG_ENDIAN)
> # define BOOST_BYTE_ORDER 4321
> #elif defined(_LITTLE_ENDIAN)
> # define BOOST_BYTE_ORDER 1234

----- Original Message -----
From: "Boris Gubenko" <Boris.Gubenko_at_[hidden]>
To: <boost_at_[hidden]>
Cc: "Boris Gubenko" <Boris.Gubenko_at_[hidden]>
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.


----- Original Message -----
From: "Johan Råde" <rade_at_[hidden]>
To: <boost_at_[hidden]>
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:

Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at