为何固定大小联合体无法规避‘flexible array member’编译错误？

我明白int g[]作为柔性数组如果不在结构体末尾会导致大小歧义，但我觉得用固定大小的联合体可以规避——联合体U大小是100字节，结构体S的大小应该是确定的（我预期是204字节）。但这段代码在C环境能正常编译运行，到C里就触发error: flexible array member ‘B::g’ not at end of ‘struct S’错误。想搞清楚为什么C不允许，同时找不用重构C代码的解决方案。

代码示例：

struct A {
    int a;
    int b;
    int c;
};

struct B {
    int d;
    int e;
    int f;
    int g[];
};

union U {
    B b;
    A a;
    uint8_t arr[100];
};

struct S {
    int b;
    U u1;
    U u2;
};

int main()
{
    U u = {{0}};
    S s = {0};

    printf("size=%lu\n", sizeof(U));

    return 0;
}

错误信息：

error: flexible array member ‘B::g’ not at end of ‘struct S’

为什么C++不允许这种写法？ #

• C标准对柔性数组的规则更宽松：在C中，只要柔性数组所在的结构体本身不是另一个结构体/联合体的成员，或者不是数组元素，就可以放在联合体里——因为联合体的大小由最大成员决定，这里uint8_t arr[100]已经把联合体大小固定为100，C编译器会忽略柔性数组对联合体大小的影响，只把它当成一个占位符。
• C根本不支持柔性数组：C标准里没有柔性数组的概念，它是C的特有语法。C++编译器碰到int g[]这种写法，会直接按照“不完整类型”来处理，而且它不会像C那样考虑联合体的固定大小来妥协，只要发现柔性数组所在的结构体被嵌套在另一个结构体（S）里，就直接报错，不管外层有没有用联合体限制大小。

可行的解决方案 #

方案1：把C代码单独编译成静态库/动态库 #

把这段含柔性数组的C代码单独用C编译器（比如gcc）编译成库文件，然后在C项目里通过头文件声明接口，链接这个库。这样C代码用C规则编译，C代码只调用接口，两边互不影响。

方案2：用C++兼容的写法替代柔性数组 #

把struct B里的int g[]改成int g[1]，然后通过内存分配的方式模拟柔性数组的功能——比如需要存n个int时，分配sizeof(B) + (n-1)*sizeof(int)的内存。这种写法在C和C++里都能正常编译，逻辑和原来的柔性数组一致。

修改后的struct B：

struct B {
    int d;
    int e;
    int f;
    int g[1];
};

方案3：给C++编译器加兼容选项 #

有些编译器（比如gcc/clang）支持-fms-extensions或者-std=c99之类的选项，强制让C++编译器兼容C的柔性数组语法。但这种方式不跨编译器，而且可能引入其他兼容性问题，不推荐作为长期方案。

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