违反严格别名规则何时无风险？相关C语言代码问题解析

一、问题核心原因及可能的未定义结果 #

你的代码主要违反了C标准的严格别名规则，同时存在对齐问题，可能导致以下意外结果：

• 严格别名规则冲突：C标准规定，除了char/uint8_t类型指针可以访问任意类型内存外，其他不同类型的指针不能用来访问同一块内存。这里将uint8_t*强制转换为uint32_t*并解引用，属于反向违规——用非字符类型指针访问字符数组，编译器会基于"不同类型指针指向独立内存"的假设做优化，可能导致：
  • 编译器优化掉buffer[0] = 8的赋值操作，因为它判定get_word访问的是与buffer无关的uint32_t变量，最终输出随机值；
  • 在更复杂的代码逻辑中，出现变量值被意外覆盖、读取到陈旧缓存数据等不可预知的行为。
• 内存对齐问题：uint32_t通常要求4字节对齐，但uint8_t buffer[4]的起始地址不一定满足该对齐要求。在ARM、MIPS等架构上，访问不对齐的uint32_t会直接触发硬件异常；即使x86架构允许不对齐访问，也会产生性能损耗，且仍属于标准定义的未定义行为。
• 你编译时未收到警告，是因为代码逻辑简单，-Wstrict-aliasing=2的检测阈值未触发，但这不代表代码行为安全。

二、违反规则却无风险的场景 #

在以下特定场景中，该代码的行为可能符合预期（但仍不具备可移植性）：

• 运行在支持不对齐访问的架构：比如x86/x86_64平台，硬件原生支持不对齐内存的读写操作，不会触发对齐异常。
• 数组起始地址满足目标类型对齐要求：通过alignas(uint32_t) uint8_t buffer[4];声明数组，强制保证起始地址为4字节对齐，消除对齐带来的问题。
• 关闭编译器严格别名优化：编译时添加-fno-strict-aliasing参数，编译器会放弃基于严格别名规则的优化，代码行为会符合预期，但会损失部分优化性能。
• 目标平台ABI明确允许该操作：部分嵌入式平台的应用二进制接口（ABI）明确认可这种字节数组转多字节类型的操作，在该平台运行时不会出现问题，但代码无法移植到其他平台。

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