... I'd suggest that *testing interoperability* is the key precaution that you should advise.
It should obviously be between all possible combinations of processor hardware types. 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 occur. (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 them!) 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. << Thanks, Paul. 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 this thread. 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 something like: 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 perform? * Test cases that probe for errors you have seen in the past or that you worry about. 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 the docs. 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. Cliff --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com