Re: [boost] [boost::endian] Request for comments/interest (floating point endian handling)

Subject: Re: [boost] [boost::endian] Request for comments/interest (floating point endian handling)
From: Tomas Puverle (tomas.puverle_at_[hidden])
Date: 2010-06-01 15:23:10

> In code I've seen where fp values are byte swapped, it's always "in-place" 
> swapping, and it's just luck that there's no code "in between the swaps" 
> that might cause normalization (or other bit changing) to occur.  For Boost 
> quality libraries, I would always vote against code that silently fails with 
> what appears to be typical, normal usage. That's why I brought up the point 
> about disallowing or explicitly supporting fp types in endian / byte 
> swapping libraries.

I think a reasonable solution to this problem would be the following:

1) Restrict the swap<>() function for floating point types (and pointers, for
that matter, as they potentially have the same problems) (who might want to send
a pointer to a device?  I don't know but I don't see a reason to disallow it)

The swapping itself is not a problem - it is done at the byte level, so floating
point registers don't get involved.  The only issue is the return value from
swap<>(), which could be in a register and could introduce the above issues. 
However, this is only a problem when swapping FROM the machine representation to
the "device" representation.  It does not exist in the opposite direction.

So we can always allow swap_in_place<>, from<>() (as suggested by Rob) and a
restricted form of swap<>() (only the {little/big}_to_host versions).

I think that should cover it.

Another possibility would be to return an opaque type which contains some number
of bytes representing the swapped data in the case of "host_to_<whatever>"
scenario.  Actually, I sort of like this idea, as it makes it clear the data is
now completely opaque and shouldn't be used any longer, other than to write it.

Tom