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