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

Subject: Re: [boost] [Review] Boost.Endian mini-review
From: Beman Dawes (bdawes_at_[hidden])
Date: 2015-01-27 08:49:48

On Mon, Jan 26, 2015 at 11:25 PM, Cliff Green <cliffg_at_[hidden]> 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.

Thanks,

--Beman