C语言结构体内部零长度数组未对齐是否属于编译器特定行为？

核心结论 #

你观察到的行为属于编译器特定的扩展特性，C语言国际标准并未对零长度数组的对齐规则做统一规定，不同编译器的实现逻辑存在差异。

原理说明 #

1. 语法属性说明
   你使用的char Label[0]零长度数组并不是标准C的语法，而是GCC、Clang等编译器提供的非标准扩展，多用于兼容老代码的标记、动态长度结构体场景。标准C从C99开始提供的官方类似特性是柔性数组成员，语法为char Label[]，且柔性数组成员只能放在结构体的最后一个位置，不支持你这种在结构体中间插入做标记的用法。

2. 地址差异的产生原因
   GCC、Clang对零长度数组的处理规则是固定的：

• 零长度数组自身占用的内存大小为0
• 零长度数组本身不会触发任何对齐填充，它的地址直接等于其前面最后一个结构体成员的结束地址
• 编译器仅会为零长度数组后面的普通成员按照对齐要求插入填充字节

对应你的第二个示例：

struct tagOBJ
{
    char Label1[0];
    int A; // 占4字节，结束地址为结构体起始地址+4
    char D; // 占1字节，结束地址为结构体起始地址+5
    char Label2[0]; // 地址直接取D的结束地址，也就是结构体起始地址+5（对应你输出的6422293）
    int B; // int要求4字节对齐，编译器在Label2和B之间插入3字节填充，所以B的地址是结构体起始地址+8（对应你输出的6422296）
    int C;
};

自然就会出现两个地址不相等的情况。

不同编译器的差异 #

• GCC、Clang的处理规则完全一致，都会遵循上述的「零长度数组不触发对齐、地址直接承接前序成员结束位置」的规则
• 微软MSVC编译器原生不支持零长度数组扩展，直接写[0]会触发编译错误，需要用其他语法替代

实用建议 #

如果你希望基于这个特性做通用实现，又要兼顾可移植性，可以考虑两个方案：

• 仅针对GCC/Clang编译的场景使用该特性，加编译宏判断规避编译器不兼容问题
• 给结构体添加__attribute__((packed))属性强制取消所有对齐填充，这样零长度数组的地址永远和后面的第一个成员地址相等，但要注意非对齐访问的性能损耗，以及部分硬件平台不支持非对齐访问的问题

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