类型双关前应使用哪些静态断言？自定义双关宏是否有遗漏？

先看你编写的类型双关宏：

#define PUN(type, var)                                                        \
        _Static_assert(sizeof(type) <= sizeof(var), "Bad pun alias");         \
        _Static_assert(_Alignof(type) <= _Alignof(var), "Bad pun alignment"); \
        (*(type *)&(var)) // only use for lvalue punning, otherwise use PUN_SAFE
#define PUN_SAFE(type, var) ({ type _##type;    \
        memset(&(_##type), 0, sizeof(_##type)); \
        memcpy(&_##type, &(var), sizeof(var));  \
        _##type; })

一、PUN宏的额外检查项 #

除了大小和对齐，还有两点需要注意：

• const变量的双关风险：如果var是const限定的，通过PUN宏强制转成非const类型并修改会触发未定义行为。静态断言没法直接检测这种场景，但必须在宏注释里明确禁止传入const变量。
• 左值合法性：虽然编译器会对右值（比如字面量）取地址报错，但还是要在宏的注释里反复强调：仅允许传入左值，避免使用者误用右值导致编译失败。

另外，类型可表示性问题（比如浮点型转整数时的位模式兼容性）属于语义问题，静态断言无法直接检查，只能靠使用者自行保证场景合法性。

二、严格别名规则与编译选项的问题 #

1. 现有静态断言不能作为启用-Wno-strict-aliasing的依据：严格别名规则的核心是「不同类型指针不能访问同一块内存（char*或兼容类型除外）」，你的静态断言只保证了大小和对齐符合要求，但并没有改变PUN宏违反规则的本质。即使大小对齐都合法，编译器依然会基于严格别名规则做优化，比如重排内存访问、删除冗余加载，最终导致代码行为异常。
2. -Os下不加-fno-strict-aliasing的风险极高：-Os虽然以优化代码大小为目标，但依然会启用大部分基于严格别名的优化。只要触发严格别名违规，不管优化等级如何都是未定义行为，BUG出现只是概率问题，-Os下同样可能出现数据不一致、逻辑跳变等严重问题。
3. 正确的处理方式：如果一定要用PUN宏，必须添加-fno-strict-aliasing禁用严格别名优化，而不是仅仅关闭警告（-Wno-strict-aliasing只是不提示警告，但优化依然会执行，BUG依然存在）。

三、PUN_SAFE的memset/memcpy优化问题 #

PUN_SAFE通过memcpy实现类型双关是C标准允许的（memcpy的void*参数绕过了严格别名规则），编译器在多数场景下能识别这种模式并优化：

• 当type和var大小相等、对齐合规时，memcpy会被优化成直接的位复制（甚至寄存器间的移动），memset也会被完全优化掉（因为后续memcpy会覆盖所有字节）。
• 无法优化的场景包括：
  • type大小大于var，此时memset未被覆盖的字节需要保留清零状态，无法优化；
  • 使用了变长数组（VLA），编译器无法在编译期确定类型大小，只能保留运行时调用；
  • 类型存在特殊对齐要求（编译器无法确认对齐兼容性）。

另外，PUN_SAFE里的memset其实是多余的：如果type和var大小相等，memset会被完全覆盖；如果type更大，清零未覆盖部分的需求是否必要取决于你的业务场景。可以考虑给PUN_SAFE也加上大小静态断言，或者直接去掉memset简化宏。

内容的提问来源于stack exchange，提问作者soapy.spacetime