On Mon, Jan 26, 2015 at 11:25 PM, Cliff Green
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. Thanks, --Beman