Re: [boost] Optimized portable isnan, isfinite, fpclassify etc

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
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_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.

Boris

----- 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:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>

_______________________________________________
Unsubscribe & other changes: 
http://lists.boost.org/mailman/listinfo.cgi/boost