Re: Byteswapping floating point types

[Andrew Troschinetz <ast at arlut dot utexas dot edu>]

On Jul 15, 2009, at 1:51 PM, Andrew Bell wrote:

> On Wed, Jul 15, 2009 at 12:20 PM, Andrew Haley<aph@redhat.com> wrote:
> > Andrew Troschinetz wrote:
> > > On Jul 15, 2009, at 10:13 AM, Andrew Haley wrote:
> > >
> > > > Andrew Troschinetz wrote:
> > > >
> > > > > It is not an area in which I am well versed so I probably can't  
> > > > > give you
> > > > > as good an answer as others on this list, but I'll give it a go.  
> > > > > "Why
> > > > > would it?" isn't actually a valid question, you should be asking  
> > > > > "why
> > > > > does it?" because all the tests I've done show that it does.
>
> The original question was about the signature/implementation of the
> swap function.  What you are talking about here really has nothing to
> do with that, right?  Unless you are trying to treat the swapped float
> as a valid (meaning useful) float, there is no problem with any
> implementation of swap, right?  In other words, it's not the swapping
> that causes the issue, its the subsequent use of the swapped value as
> meaningful on the system, where it really has no business being
> interpreted as such.

Is it possible you sent this response before my back and forth with  
Andrew Haley was posted to the list? Also what the heck, three Andrews!

The problem with the signature is that a byteswapped floating point  
value placed in a floating point type will cause some hardware to flip  
bits in the value. You can avoid this issue by returning either an  
accommodating integral type acting essentially like a byte-sequence,  
or an actual byte-sequence. In these ways a byteswapped floating point  
value never runs the risk of being transmogrified by the FPU.

--
Andrew Troschinetz
Applied Research Laboratories