According to basic.lval, it is legal to access an object through char; however, according to basic.compound, char* is not pointer-interconvertible with something like int*, meaning that they may result in different values during casting.
Thus the code below:
static_assert(sizeof(int) == 4);
int a = 0xFFEE2211;
char* b = reinterpret_cast<char*>(&a);
assert(b[0] == '\x11'); // check whether it's little-endian.
may result in a b with a different address value from &a whose type is int*. So my question is how is it ensured that the first byte read by b is 0x11 rather than like 0x22? More generally, which rule ensures that the memory bytes of an object can be fully accessed by char* as if a byte array with a size of sizeof(obj)?
>Solution :
It currently isn’t ensured. Technically, forming a pointer to anything but the first byte through the char* pointer has undefined behavior, because any pointer arithmetic on b, including b[0] has undefined behavior. There is also no proper definition at the moment how the value of *b should be determined as it is not specified to be the value of the object representation, but rather the value of the int object itself. So that’s probably undefined behavior as well.
The proposal P1839 is trying to fix that, although I am not sure at the moment whether the proposed wording would require a cast to unsigned char* instead of char*.
But even with that, it is implementation-defined which bits would be read from the int. That would be determined by endianess and an implementation is also permitted to use mixed endianess. For example the first byte in the object representation could be 0x22 and the second byte could be 0x11.