转换字节序时为何要联合uint8_t[4]数组与uint32_t？

一、触发UB的具体场景 #

1. 严格别名规则违规 #

C标准的严格别名规则规定：不同类型的指针（除char/unsigned char外）不能指向同一块内存并直接访问，否则属于未定义行为（UB）。

比如直接将unsigned char数组的指针强制转换为uint32_t*读取：

unsigned char bytes[4] = {0x12, 0x34, 0x56, 0x78};
uint32_t val = *(uint32_t*)bytes; // 违反严格别名规则，UB

编译器会基于“不同类型指针不会别名”的假设做优化，比如提前读取val的值、重排代码逻辑，最终运行结果可能完全不符合预期。

2. 内存对齐错误 #

多数平台对uint32_t这类32位类型有对齐要求（比如地址必须是4的整数倍），而unsigned char数组的地址可能不满足该要求。此时强制转换指针并访问会触发硬件异常或UB：

// 强制让数组地址不满足4字节对齐
unsigned char bytes[4] __attribute__((aligned(1))) = {0x12, 0x34, 0x56, 0x78};
uint32_t val = *(uint32_t*)bytes; // 对齐错误，UB

部分架构（如ARM）会直接抛出总线错误，导致程序崩溃；即使没有崩溃，读取的值也可能是乱码。

注意：移位拼接是安全的 #

你提到的“通过移位生成指定字节序”本身是安全的，比如：

// 手动拼接大端字节序为32位值，无UB
uint32_t big_endian_val = (bytes[0] << 24) | (bytes[1] << 16) | (bytes[2] << 8) | bytes[3];

这种方式是逐个读取unsigned char成员，再通过位运算组合成32位值，既不违反别名规则，也不存在对齐问题。触发UB的是直接强制转换指针访问的错误写法，而非移位操作。

二、联合类型如何规避这些问题 #

联合的核心特性是所有成员共享同一块内存空间，C标准明确允许通过联合的一个成员写入，再通过另一个成员读取（只要类型兼容或为字符类型），完美解决上述两个问题：

1. 解决对齐问题 #

联合的内存对齐会遵循其成员中对齐要求最严格的类型（比如uint32_t要求4字节对齐），因此联合内的unsigned char数组地址必然满足uint32_t的对齐要求，不会出现对齐错误。

2. 规避严格别名违规 #

标准允许通过联合的不同成员访问同一块内存，不属于严格别名规则的违规场景。

示例代码：

union EndianConverter {
    uint32_t u32;
    unsigned char u8[4];
};

// 写入字节序列
union EndianConverter conv;
conv.u8[0] = 0x12;
conv.u8[1] = 0x34;
conv.u8[2] = 0x56;
conv.u8[3] = 0x78;

// 读取对应的32位值，无UB
uint32_t val = conv.u32;

适用场景 #

联合适合读取内存中已有字节序列对应的主机字节序32位值；而移位操作适合主动生成指定字节序（大端/小端）的32位值，两者可以根据需求选择。

内容的提问来源于stack exchange，提问作者basedchad21