Consider we have a sequence of bytes whose value representation like the following
00000000, 00000000, 00000001, 00000000
It designates the integer value 256 on machine A, which is encoded by big-endian. Assume the destination machine is little-endian. Now, we have common functions like that
unsigned long octets_to_unsigned32_little_endian(unsigned char *p)
{
return p[0] |
((unsigned)p[1]<<8) |
((unsigned long)p[2]<<16) |
((unsigned long)p[3]<<24);
}
/* long octets_to_signed32_little_endian(unsigned char *p)
{
unsigned long as_unsigned = octets_to_unsigned32_little_endian(p);
if (as_unsigned < 0x80000000)
return as_unsigned;
else
return (long)(as_unsigned^0x80000000UL)-0x40000000L-0x40000000L;
} */
However, [basic.types.general] p4 says
For trivially copyable types, the value representation is a set of bits in the object representation that determines a value, which is one discrete element of an implementation-defined set of values.
In the above example, regardless of how we retrieve the integer from the buffers, it always depends on how the value representation of the integer is. In other words, the implementation of the above functions always assumes the value representation of the integer value in the destination machine is 00000000 00000001 00000000 00000000. In other words, the implementation can consider the value representation of the value 256 to be 00000000 10000000 00000000 0000000, or 00000000 11111111 10101010 0000000, or anyway, which does not violate the requirement of the standard.
Two questions
- Retrieve an integer from the byte buffers is implementation-defined?
- Is there any way that can get rid of implementation-defined?