基于联合体的类型双关与混合C/C++代码的安全性咨询

算力阿峰

2026-4-13

你好呀！我来帮你梳理下混合C/C++代码里用联合体做类型双关的安全性问题~

首先先明确你的场景：你有一个用联合体实现类型双关的C代码库，现在要用C的gmock做单元测试，但你知道C标准里这种联合体类型双关是非法的，所以想确认自己的用法会不会踩坑。

咱们先来理清楚C和C++在这事儿上的核心差异：

C标准（C99及以后）：联合体的类型双关是明确合法的——只要你访问的是最后一次写入的成员，或者用字符类型（比如unsigned char）来读取字节，完全符合标准，没有问题。
C++标准：情况就严格多了，除非是用字符类型访问联合体成员，否则读取联合体里不是最后写入的成员属于未定义行为。不过好在大多数主流编译器（比如GCC、Clang、MSVC）都提供了扩展支持，允许这种C风格的联合体类型双关，很多时候默认就开着这个支持。

接下来针对你的混合代码场景，给你几个具体的建议：

C代码部分放心用：你的C代码只要符合C99+标准，用C编译器编译，那里面的联合体类型双关逻辑是完全安全合规的，这部分不用纠结。
C++测试代码调用C函数的情况：
- 如果你的C测试代码只是调用C代码里的函数（比如你提到的sum_halves），类型双关的逻辑完全在C编译单元里实现，那基本没什么问题——因为C代码是按C标准编译的，C代码只是调用编译好的二进制函数，不会触发C++里的未定义行为。
- 但如果你的C测试代码里要直接操作那个用于类型双关的联合体，那就要注意了：要么依赖编译器的扩展支持（比如GCC/Clang默认允许，MSVC也有对应选项），要么改用C标准明确允许的方式来做类型双关，比如用std::memcpy复制字节。
用std::memcpy替代联合体（C++里更稳妥的选择）：如果在C++代码里需要做类似的类型转换，std::memcpy是标准明确认可的合法方式，完全不会有未定义行为。举个例子：
```
#include <cstdint>
#include <cstring>

uint32_t sum_halves_cpp(uint64_t i) {
    uint32_t halves[2];
    std::memcpy(halves, &i, sizeof(i));
    return halves[0] + halves[1];
}
```

举个实际的例子，假设你的C代码是这样的：

// sum_halves.c
#include "sum_halves.h"
#include <stdint.h>

union U {
    uint64_t full;
    struct {
        uint32_t low;
        uint32_t high;
    } halves;
};

uint32_t sum_halves(uint64_t i) {
    union U u;
    u.full = i;
    return u.halves.low + u.halves.high;
}

这段C代码完全符合C标准，安全可靠。你的C测试代码只要调用sum_halves函数，而不直接操作union U，那在C里调用是完全安全的。

总结一下：

只要类型双关的逻辑都放在C代码里，用C编译器编译，C++测试代码只做函数调用，你的用法就是安全的。
如果C++代码里需要自己实现类型双关，优先用std::memcpy这种标准允许的方式，或者确认编译器支持联合体类型双关的扩展。

备注：内容来源于stack exchange，提问作者Dominik Kaszewski