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