为什么memcpy将整数目标处理为Big Endian，但不将其处理为char目标？

如何解决为什么memcpy将整数目标处理为Big Endian，但不将其处理为char目标？

我正在运行以下代码的计算机是Little Endian。

uint32_t src_uint = 0xAABBCCDD;
uint32_t dest_uint = 0;
uint8_t dest_arr[4] = {0};

memcpy(&dest_uint,&src_uint,4);
printf("\ndest_uint: 0x%X\n",dest_uint);
// output: 0xAABBCCDD

memcpy(dest_arr,4);
printf("\ndest_arr : 0x");
for (int i = 0; i < 4; i++)
    printf("%X",dest_arr[i]);
// output: 0xDDCCBBAA

对我来说，第二个输出（0xDDCCBBAA）是正确的，因为我的计算机是低字节序的。但是，第一个输出（0xAABBCCDD）应该改为0xDDCCBBAA，因为Little Endian会将变量src_uint存储在内存中为：0xDDCCBBAA。似乎memcpy（）的参数不是透明的，或者在这种情况下C编译器对int的处理方式不同。

谢谢！

解决方法

对我来说，第二个输出（0xDDCCBBAA）是正确的，因为我的计算机是低端字节序。

或者换句话说，该输出证明您的C实现确实对类型uint32_t使用了低端字节表示。

但是，第一个输出（0xAABBCCDD）应该改为0xDDCCBBAA，因为Little Endian会将变量src_uint存储在内存中为：0xDDCCBBAA。

这个结论并非源于先前的结论。是的，src_uint的值在内存中表示为字节序列0xDD 0xCC 0xBB 0xAA。并且有充分的理由认为memcpy会忠实地将该字节序列复制到dest_uint的表示形式中。当您的程序将该表示形式解释为uint32_t类型的值时，十六进制的人类将结果值表示为0xAABBCCDD。

如果您也打印src_uint的值，则会得到相同的结果。

不要混淆数字类型的对象表示的数字值和这些值的内存表示形式。正如您所演示的，C程序可以并且确实暴露了后者，但是大多数操作是根据前者定义的。

,

这与nextInt()无关，而与您访问目的地的方式有关。在第一种情况下，您将以num % 2的形式访问该值。在第二种情况下，您一次访问一个字节的内存。

在大型字节序系统上，这些将给您相同的结果。在小端系统上，结果相反。