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