Re: [boost] [Review] Boost.Endian mini-review

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: 27 January 2015 13:50 To: Boost Developers List Subject: Re: [boost] [Review] Boost.Endian mini-review

On Mon, Jan 26, 2015 at 11:25 PM, Cliff Green wrote:

...

...

Is the library ready to be added to Boost releases?

Yes.

I have used Beman's Endian library from 2011 extensively and have been completely satisfied by it. This newer version provides the original functionality plus adds extensive new useful functionality (and will allow me to replace some of my "homegrown" endian utility code).

However, I do have concern about one aspect of the new functionality (or maybe I didn't read deep enough in the docs) - floating point endian reversal functions which return by value.

Unless something has significantly changed in the last few years, swapping and returning floating point values is likely to silently change bits for certain bit patterns / values. In particular, returning by value will normalize some values (I assume as part of loading or accessing the value into floating point CPU registers). There may be other floating point characteristics that silently change the bits dealing with NaN and infinity values (but I'm far from an expert on floating point computations).

I've never seen the normalization happen for in-place swapping of floating point values, only when returning by value.

This means that, for certain values of x, where x is floating point: endian_reverse(endian_reverse(x)) != x. (Note that for integers, endian_reverse(endian_reverse(x)) == x, for all possible values of x.)

Maybe I missed something in the docs where the normalization is turned off, or an exception thrown, or somehow this situation is addressed (and again, it's only for the conversion functions returning by value). Some of the Boost floating point / computation experts might want to chime in.

I've worked in multiple projects that blithely swapped floating point values in various distributed processing environments, rarely paying attention to these kinds of issues (as well as more obvious issues, like whether all systems were IEEE 754 or not), and most of the time they were "lucky", happening to write home-grown code that swapped in place and was careful not to move the swapped floating point values out of buffers before reading or writing. I always mentioned this code was brittle and to pay attention or document the brittleness.

Cliff,

Thank you very much for this post! You have identified a serious weakness.

The underlying problem is that I have virtually no experience with floating-point issues. So if you or others could help improve endian floating point support, it will be greatly appreciated.

Here are some areas where help is needed:

* Recommendations for changes to the library interface for floating point. For example, eliminating the return by value functions. * Test cases that probe for errors you have seen in the past or that you worry about. * Suggestions about warnings or other changes you would like to see made to the docs. * Should the implementation refuse to compile (i.e. #error) on no-IEEE 754 systems? If so, how to implement? * Anything else that you can think of to improve FP support.

The proof of the pudding is in the eating. I'd suggest that *testing interoperability* is the key precaution that you should advise. It should obviously be between all possible combinations of processor hardware types. The test should include a range of floating-point values from min to max, and include NaN and infinity unless it is certain that they will never occur. (Unless very special precautions are taken, then infinity and NaN are like to rear their ugly heads at some time - probably when you least want to see them!) It must be possible to 'round-trip' all floating-point values. You can't test all possible values (except for 32-bit float - 64-bit double takes about 50 years at current processor speeds ;-) but you can chose values (floating-point bit patterns) at random for a test lasting some minutes or even hours. (This was the only way that I found to check for failures in Microsoft cout - cin round-tripping (a feature not a bug) that are relevant to serialization). Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830