Created on 2023-08-06.00:00:00 last changed 1 month ago
This wording is relative to N4950.
Modify the [bit.endian] as indicated; using removed wording from C++17:
If all scalar types have size 1 byte, then all of endian::little, endian::big, and endian::native have the same value. Otherwise, endian::little is not equal to endian::big. If all scalar types are big-endian, endian::native is equal to endian::big. If all scalar types are little-endian, endian::native is equal to endian::little. Otherwise, endian::native is not equal to either endian::big or endian::little.
[bit.endian] says that "big-endian" and "little-endian" refer to whether bytes are stored in descending or ascending order of significance. In other words, when std::endian::native is either std::endian::big or std::endian::little, we are told something about the object representations o f multi-byte scalar types. However, the guarantee provided in this case is not strong enough to fully specify the object representation, even in the common situation where padding bits are not present. It would be more useful to provide a stronger guarantee.Consider, for example, if char is 8 bits and there is an uint32_t type on the current platform. If std::endian::native is std::endian::little, then the program should be able to rely on the fact that if a uint32_t object is copied into an array of 4 unsigned char, then the value of the first element of that array actually equals the original value modulo 256. However, because P1236R1 removed the core language specification of the value representation of unsigned integer types, the program cannot actually rely on this. It is conceivable (though unlikely), for example, that std::endian::native could be std::endian::little but the first byte in a uint32_t object is actually the least significant 8 bits flipped, or the least significant 8 bits permuted, or something like that.
|2023-08-12 12:19:59||admin||set||messages: + msg13705|