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
>> -----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,
>> 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
>> 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
>> that only in-place reverse is available for FP. That will give us more time to determine if
>> endianness reverse is valid for floating point.
> I'm not sure.
> This looks like a NaN?
> As I said before, I'd explicitly not make promises for any NaN except
> (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.