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