On Fri, Mar 20, 2015 at 1:50 PM, Paul A. Bristow
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] 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