Re: [boost] [boost::endian] Request for comments/interest (floating point endian handling)

Subject: Re: [boost] [boost::endian] Request for comments/interest (floating point endian handling)
From: Cliff Green (cliffg_at_[hidden])
Date: 2010-05-27 14:43:49

For generic endian conversions, keep in mind the restrictions for floating 
point types (and other types with similar properties). It might be 
worthwhile putting in an "is_integral" check in the generic function 
implementations.

I see a number of projects where I work that blithely endian swap and pass 
around binary floating point values in distributed applications, not 
understanding the brittleness of this design.

For example, in the following:

>   template <class T, class U>
>   T
>   big_endian_cast(U);
>
>  (and similar little_endian_cast function)

If T and U are floating point types, then:

double val1 = someVal; // little endian, for example
// ...
double val2 = little_endian_cast<double>(big_endian_cast<double>(val1));

For many values, val1 != val2; (For all integral types in the above casting 
functions, all possible values will have val1 == val2.)

This is due to floating point normalization and other non-obvious operations 
that might be silently applied to the internal bits when values are moved to 
/ from registers.

And, even though IEEE 754 is pretty much the standard floating point 
implementation on modern platforms, that shouldn't be assumed.

I can't remember if Beman's endian facilities addressed floating point 
swapping, but any accepted Boost endian facility needs to address 
non-integral types in some form or fashion (either by restricting, or 
properly implementing).

I faintly remember some discussions on this subject in the Serialization 
portable binary archive, or maybe in the Math floating point utilities, but 
a quick glance at 1.43 documentation doesn't provide specific code for 
endianness handling in either library (I may have missed it).

Cliff