编译时类型转换疑问：指针强制转换传递union参数是否安全？

先给出涉及的联合类型和函数定义：

/**
 * @brief   保存参数的16位值变体表示
 */
typedef union
{
    uint16_t    u;  /*!< 无符号16位整数 */
    int16_t     i;  /*!< 有符号16位整数 */
} hparamValue_t;

void hparam_set(const hparamValue_t value);

原调用方式是创建临时联合变量赋值后传递：

uint16_t myVar; // 已初始化的变量
// 调用函数
hparamValue_t hpv;
hpv.u = myVar;
hparam_set(hpv);

现在想改用hparam_set(*((hparamValue_t*)&myVar))的写法，无需临时变量，以下是针对疑问的解答：

1. 指针强制转换再解引用的操作是否会在编译时展开？ #

会的。在开启常规优化（比如-O1及以上）的情况下，编译器能识别出这种写法和临时变量赋值的逻辑等价性：因为uint16_t、int16_t和hparamValue_t的内存大小完全一致（都是2字节），且联合的起始地址与成员地址重合，编译器会直接将该操作优化为直接传递myVar的数值，不会生成实际的指针转换、解引用指令，相当于编译时就“展开”成了和临时变量写法完全一致的机器码。即使是低优化级别，最多生成简单的指针操作指令，不会有额外性能开销。

2. 该写法是否安全？存在哪些潜在风险？ #

这种写法在大多数常见平台（如x86、ARM）的实际运行中能正常工作，但不符合C语言标准，属于未定义行为，存在以下潜在风险：

• 违反严格别名规则：C标准的严格别名规则规定，程序不能通过与对象声明类型不兼容的指针类型访问对象（char*和联合成员访问除外）。这里将uint16_t*强制转换为hparamValue_t*并解引用，本质是用联合类型访问uint16_t类型的对象，违反了该规则。在高优化级别下，编译器可能基于“对象只会被同类型指针访问”的假设进行优化，导致代码逻辑出错（比如错误缓存myVar的值，忽略实际修改）。
• 极端平台的兼容性问题：虽然当前两个成员都是16位整数，但如果后续联合类型被修改（比如新增不同对齐要求的成员），或者在某些特殊对齐要求的平台上，hparamValue_t的对齐要求可能高于uint16_t，此时强制转换可能导致对齐错误，触发程序崩溃或内存访问异常。

更安全的替代写法 #

如果想避免临时变量又符合标准，可以使用C99及以上支持的复合字面量：

// 针对uint16_t变量
hparam_set((hparamValue_t){.u = myVar});
// 针对int16_t变量
hparam_set((hparamValue_t){.i = myIntVar});

这种写法既不需要临时变量，又完全符合C语言标准，不存在未定义行为的风险。

内容的提问来源于stack exchange，提问作者Łukasz Przeniosło