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

Subject: Re: [boost] [endian] Testing floating point interoperability
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2015-03-20 13:50:56

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

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]