Boost logo

Boost :

Subject: Re: [boost] [endian] Project not maintained
From: Peter Dimov (lists_at_[hidden])
Date: 2016-04-04 07:54:14

Gavin Lambert wrote:
> If you have API that can take a void* or char* (or other
> block-of-bytes-of-appropriate-size) and then reinterpret this as a
> big-endian or little-endian float/double/longdouble (returning the native
> representation), then this can work and is a useful function. Similarly
> taking a native float/double/longdouble and writing it to a block-of-bytes
> in a specified endian format.

"Little-endian float" is not enough information. Floating point formats are
not fully described by their endianness. (Neither are integer formats in
principle, but in practice they are.)

Apart from that, I agree. char[4] /* IEEE 32 bit little endian float */ <->
float is a correct interface. Or even uint32_t <-> float.

    uint32_t float_to_bits( float x );
    float float_from_bits( uint32_t v );

If you have that, you can then byteswap the unit32_t to your heart's
content, even though the correct interface there is also char[4] /* little
endian 32 bit */ <-> uint32_t.

> As a Boost.Endian library user, until the first style of API is
> implemented you can work around it by doing endian swaps on unsigned
> integers only, and using a bitwise_cast-equivalent to convert between the
> floating-point values and unsigned integers of appropriate size.

Something like that, yes, but what I'm suggesting is not a bitwise cast.
There need not be any correspondence between the uint32_t bits and the float
bits, because the uint32_t is IEEE, and the float is native.

Technically, this could also be true for integers; the char[4]
representation is 32 bit with no padding and no trapping, and the uint32_t
(which would have to be uint_least32_t) may have them. (Although this
assumes CHAR_BIT == 8. I'm not sure what is the right interface when
CHAR_BIT is 32.)

Boost list run by bdawes at, gregod at, cpdaniel at, john at