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,
> 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.
--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk