Boost logo

Boost :

Subject: Re: [boost] [endian] Project not maintained
From: Peter Dimov (lists_at_[hidden])
Date: 2016-04-04 12:37:18


Andrey Semashev wrote:

> > void write_be32( uint_least32_t n, unsigned char p[4] )
> > {
> > // I assume CHAR_BIT of 8 here
> >
> > /* assert( n < 2^32 ); */
> >
> > p[0] = ( n >> 24 ) & 0xFF;
> > p[1] = ( n >> 16 ) & 0xFF;
> > p[2] = ( n >> 8 ) & 0xFF;
> > p[3] = n & 0xFF;
> > }
>
> For example, uint_least32_t could have non-base-2 representation, so as
> unsigned char, so the bit patterns that are stored to p would be also not
> base-2.

The representation of uint_least32_t doesn't matter. The expression n & 0xFF
gives you a number between 0 and 255 that contains the lowest 8 VALUE bits
of n, which is not the same as the STORAGE bits of n. In no possible
representation would an uint_least32_t n with a value (m * 256 + 232) give
you something other than 232 from (n & 0xFF).

> I agree that byte swapping is rarely the end goal. But in practice, with
> some restrictions, like assuming base-2 integers and 8-bit bytes across
> all systems you're planning to run your code on, endian conversions can
> serve as a means of data serialization.

And my point is that the interface you gave handles representational
differences with the same ease as it handles differences that are limited to
a byte swap.

It's actually the same for float. If your base is

    void write_le32( float x, unsigned char p[4] );

the interface remains the same no matter what the representation of x. What
matters is that you get a little-endian 32 bit IEEE float in p.

If however you go for

    float byteswap( float x );

then things get hairy even if restricted to IEEE, because an ordinary number
may turn into a signaling NaN when byteswapped.


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