Re: [boost] [endian] Project not maintained

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.)