Re: [boost] [endian] Testing floating point interoperability

Subject: Re: [boost] [endian] Testing floating point interoperability
From: Beman Dawes (bdawes_at_[hidden])
Date: 2015-03-22 08:58:37

On Fri, Mar 20, 2015 at 1:50 PM, Paul A. Bristow
<pbristow_at_[hidden]> wrote:
>> -----Original Message-----
>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Beman Dawes
>> Sent: 20 March 2015 13:40
>> To: Boost Developers List
>> Subject: Re: [boost] [endian] Testing floating point interoperability
>>
>> An exhaustive return-by-value round-trip test of all 4 billion possible bit patterns for float
> (but not double)
>> has been run on Windows with the GCC and Microsoft compilers.
>>
>> For both compilers in release mode, and for GCC in debug mode, all bit patterns pass.
>>
>> But for Microsoft in debug mode, certain bit patterns do not round-trip correctly. For example,
> 7f810000
>> becomes 7fc10000. (Those are little endian representations).
>>
>> So what should Boost.Endian do? There is less than two weeks left before 1.58.0 ships, and even if
> this
>> turns out to be a bug in the Microsoft compiler, it is likely to cause user problems.
>>
>> The most conservative approach is to remove the return-by-value reverse functions, and note in the
> docs
>> that only in-place reverse is available for FP. That will give us more time to determine if
> return-by-value
>> endianness reverse is valid for floating point.
>>
>> Opinions?
>
> I'm not sure.
>
> This looks like a NaN?
>
> As I said before, I'd explicitly not make promises for any NaN except
>
>   std::numeric_limits<>::quiet_NaN
>
> (not even the deprecated signalling_NaN)
>
> Anyone using another NaN is likely to be not portable and not expecting Boost to be portable anyway?
>
> But Peter Dimov's objection may be more significant.

+1

--Beman