Re: [boost] [Boost-users] [Review] Boost.Endian mini-review

Subject: Re: [boost] [Boost-users] [Review] Boost.Endian mini-review
From: Beman Dawes (bdawes_at_[hidden])
Date: 2015-02-11 10:03:42

On Sun, Feb 1, 2015 at 10:20 AM, Niall Douglas
<s_sourceforge_at_[hidden]> wrote:
> On 1 Feb 2015 at 14:33, Bjorn Reese wrote:
>
>> The endian_reverse() functions assume that there are only two types of
>> endianness (big and little) and that they are the reverse of each other.
>> In practice, this is a feasible assumption. However, once in a while, an
>> odd endianness does show up in this millennia. For example, ARM11
>> processors uses mix-endian [1] for double. Byte reversal will not
>> handle such cases correctly. The could become a problem during C++
>> standardization.
>
> Another big problem for standardisation is that Endian only supports
> CHAR_BIT == 8. I recently had a pull request come through for my
> nedtries library adding CHAR_BIT = 10 support. I guess 10 bit per
> byte CPUs are still common enough, and a bit more surprisingly they
> can compile modern libraries.

Actually, the library specification for the endian types does support
CHAR_BITs other than 8.
Likewise built-in integers with sizes other than 8, 16, 32, and
64-bits. Ones complement integers should also work, and probably
sign-magnitude too.

The current implementation has only been tested on twos-complement
8-bit byte machines with 8, 16, 32, and 64-bit built-in integers.
That's why it asserts on CHAR_BIT == 8. Various optimizations may have
to be disabled before the code would work correctly.

The C++ committee's library working group is OK with conversion
functions with various limitations, and had included some in the
Library Fundamentals TS 1. The only reason they got pulled was because
on many platforms the names were already in use as macros, and there
wasn't time to come up with a new set of names.

Thanks,

--Beman