Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk