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

Subject: Re: [boost] [Review] Boost.Endian mini-review
From: Cliff Green (cliffg_at_[hidden])
Date: 2015-01-26 23:25:12

>    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

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com