On Sun, Feb 1, 2015 at 10:20 AM, Niall Douglas
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