Subject: Re: [boost] [Review] Boost.Endian mini-review
From: Cliff Green (cliffg_at_[hidden])
Date: 2015-01-30 12:17:21
>> ... I'd suggest that *testing interoperability* is the key precaution
>> that you should advise.
It should obviously be between all possible combinations of processor
The test should include a range of floating-point values from min to max,
and include NaN and infinity unless it is certain that they will never
(Unless very special precautions are taken, then infinity and NaN are like
to rear their ugly heads at some time - probably when you least want to see
It must be possible to 'round-trip' all floating-point values.
You can't test all possible values (except for 32-bit float - 64-bit double
takes about 50 years at current processor speeds ;-) but you can chose
values (floating-point bit patterns) at random for a test lasting some
minutes or even hours.
I was going to start another discussion thread asking for suggestions from
some of the experts (or at least people more expert than me) dealing with
floating point endian swapping, but I'll wait to see if we get responses on
I'm still not sure what to suggest to Beman for the Endian library wrt to
float and double API's, specially as this library could or should be the
basis for a standardization proposal. Integers are completely safe and
well-defined for swapping - all bit patterns form valid integers and
swapping bytes never result in "special" hardware processing. This is not
the case for floating point. I have definitely seen "in-place" floating
point swapping used extensively without problems, and have definitely seen
other functionality have problems (my previously mentioned "returning
swapped floating point by value causes silent changing of bits"
normalization issue). And, of course, there's the additional problem of
binary floating point interoperability between IEEE-754 processors and those
that are not.
Boost.Endian does not (and should not) define wire protocols. It provides
functionality and API's for translating to and from wire protocols. But with
floating point, any kind of standardization will have to not only define the
API, but some form of wire protocol. Then the Endian functions become
opaque_binary_type native_to_interoperate_fp(float x); // opaque_binary_type
stores fp elements - sign, mantissa, exponent, etc
opaque_binary_type native_to_interoperate_fp(double x);
float fp_interoperate_to_native(opaque_binary_type x);
double fp_interoperate_to_native(opaque_binary_type x);
Unless there is something I'm missing.
Here's my initial (and incomplete) answers to Beman's queries to my e-mail:
* Recommendations for changes to the library interface for floating point.
For example, eliminating the return by value functions.
Eliminating the floating point "return by value" function should definitely
should be performed. Whether the "in place" swap should be removed I'd like
to hear from others more expert. Specifically, with common hardware
architectures, what are the operations that will invoke floating point
normalization (and other "bit changing" functionality)? What is safe to
* Test cases that probe for errors you have seen in the past or that you
Paul gave a pretty good summary in his reply about the general testing
strategy. I don't have specific test cases, so maybe others more expert can
chime in with specific test logic.
* Suggestions about warnings or other changes you would like to see made to
Definitely some kind of summary of these warnings and "brittleness" should
be included in the docs. Probably no more than a paragraph or two of general
"watch out". I'll be happy to help. If we get responses from people more
expert at the hardware instruction level (i.e. what is really going on
"under the covers") summaries of those discussions can be included.
* Should the implementation refuse to compile (i.e. #error) on no-IEEE 754
systems? If so, how to implement?
Not sure - if we're not defining a floating point wire protocol, then it
doesn't matter what the underlying bit pattern of a swapped floating value
is. It's up to the application to know what's "on the wire" and whether it
can be safely unswapped back to native float or double (just like it's up
the application to know the underlying integer wire protocol).
* Anything else that you can think of to improve FP support.
Hopefully this is a good start and others will chime in and you'll have a
useful and safe (even if not 100% complete) initial API and implementation.
--- This email has been checked for viruses by Avast antivirus software. http://www.avast.com