GCC普通数组与std::array的严格别名规则差异及版本疑问

咱们把问题拆解开来，逐个分析背后的编译器实现细节：

1. 为什么GCC 5.4.0中std::array的操作没触发警告？ #

核心原因是GCC 5.4.0对std::array的内联分析不够彻底。

在GCC的实现里，std::array<uint8_t,12>本质是一个包含私有C数组成员的结构体（大致结构是struct array { uint8_t __elems_[12]; };）。当你调用array[1]时，实际是调用std::array::operator[]函数，它返回一个uint8_t&。虽然这个函数是inline的，但GCC 5.4.0在做strict-aliasing检查时，没有完全追踪到这个引用最终指向的是结构体内部的uint8_t数组元素——它只看到你取了一个函数返回引用的地址并做了类型转换，没识别出这个指针的原始类型是uint8_t*，因此没触发警告。

而普通C数组的&buf[1]是直接取数组元素的地址，编译器能直接识别出这是uint8_t*，转成uint16_t*解引用完全符合strict-aliasing规则的违反场景，所以直接抛出警告。

2. 为什么GCC 7.2+不再出现这个警告？ #

这是因为GCC 7系列对-Wstrict-aliasing的检查逻辑做了针对性优化调整。

严格来说，用uint16_t*访问uint8_t数组确实违反了strict-aliasing规则，但这种操作是字节级序列化/反序列化的常见写法，很多开发者都会这么用。GCC团队在7.x版本中改进了警告的准确性，减少了这类“符合开发者实际意图但严格违反标准”的误报——或者说，编译器开始识别这种场景是用户在做字节访问，而非真正的类型别名滥用，因此不再触发警告。

另外，GCC 7对std::array的内联分析也更彻底了，但这时候它反而不会对普通数组触发警告了，因为整体的警告策略已经调整，不再对这种字符类型数组转其他类型指针的操作报警。

补充：虽然编译器不警告了，但这种写法在C++标准层面依然是未定义行为。如果想彻底避免风险，更安全的写法是用std::memcpy完成数据拷贝：

std::memcpy(&buf[1], &data, sizeof(data));
std::memcpy(&array[1], &data, sizeof(data));

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