将指针转换为结构体首个成员类型与转换为联合体类型的差异及严格别名未定义行为问题咨询

Hey，我来帮你捋捋这个严格别名的坑，毕竟ARM Clang在-Os（平衡优化）加LTO（链接时优化）的配置下，优化力度拉得很满，很容易触发这类未定义行为（UB）。

先结合你的场景拆解问题：你定义的sCANFrame结构体无填充且按4字节对齐，这一点很关键，但严格别名的规则陷阱可不止对齐这么简单。

1. 指针转结构体首个成员类型的情况 #

比如把sCANFrame*强制转换成u32*去访问开头的位域成员——这种操作其实是合规的。因为C标准里有个特殊例外：指向结构体的指针，和指向它第一个成员的指针是内存布局兼容的，用后者访问第一个成员不会触发严格别名违规。不过要注意，位域的内存排布是编译器说了算的，虽然你说结构体无填充，但ARM Clang对32位位域的排列逻辑得和你的预期匹配，不过这属于编译器实现细节，和严格别名本身没关系。

2. 指针转联合体类型的情况 #

这里得分两种场景看：

• 如果是直接把sCANFrame*转成内部联合体的指针（比如u8 (*)[8]），那妥妥违反严格别名规则。因为你用联合体类型的指针，去访问结构体里非联合体成员的内存区域（前面的u32位域、u16 dlc和fmi），编译器会默认这两个指针指向完全不同类型的对象，进而做出错误的优化——比如把某个值缓存到寄存器里不更新，导致你读不到最新数据，或者写入操作直接被优化掉，这就是你遇到的UB根源。
• 但如果是通过结构体本身的联合体成员访问（比如frame->byte[0]），那完全没问题。C标准明确允许联合体的不同成员互相别名访问，这是严格别名规则的另一个例外，编译器会考虑到这种内存复用的情况，不会瞎优化。

给你的小建议 #

既然用了-Os+LTO这种高优化配置，尽量别搞指针强制转换：

• 优先直接通过结构体成员访问数据，比如frame->id、frame->byte[2]，这是最安全的方式；
• 如果非得转指针，用char*——因为char*可以别名任何类型，这是规则允许的；
• 实在没办法的话，也可以加编译选项-fno-strict-aliasing禁用严格别名检查，但这会牺牲一部分优化效果，所以尽量不用。

备注：内容来源于stack exchange，提问作者Evgeny Ilyin