Boost logo

Boost :

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

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).


Boost list run by bdawes at, gregod at, cpdaniel at, john at