GCC处理C静态存储期初始化表达式的未文档化行为问询

首先明确结论：这个行为不是GCC的代码疏漏类Bug，是GCC沿袭数十年的刻意设计的扩展行为，具体成因可以拆成几点说明：

• 首先要纠正一个常见误解：C标准从来没有要求编译器遇到约束违规就必须终止编译、拒绝生成可执行文件，从C90到后续所有版本的标准，都只要求实现针对约束违规输出至少一条诊断信息。你看到GCC“不报错”，本质是它根本没把这类场景归为需要触发诊断的违规，不是识别不到初始化表达式里有变量。
• GCC的常量表达式校验逻辑从早期版本开始就没有严格卡死标准文本的语法规则。和Clang严格按照“常量表达式允许出现的语法元素”做静态校验的思路不同，GCC长期采用更宽松的判定规则：只要表达式能在编译阶段折叠为确定的常量值，就可以当常量使用。你第一个例子里的x-x+10、x*0+5，在GCC中端做算术化简时，会直接抵消掉所有和x相关的项，得到和x取值完全无关的确定值10、5，后续处理静态存储期变量初始化时，就直接拿化简后的值用了，根本不会走到“初始化式必须为标准定义的常量表达式”的校验分支。
• 你举的第二个变长数组测试用例刚好能印证这个逻辑：块作用域下的int y[x-x+2]声明，在C90标准里本身就属于不支持的变长数组语法场景，GCC在这里走的是数组声明的独立校验逻辑——哪怕表达式最终能折叠成常量2，只要语法层面不符合C90对常量表达式的要求，在-ansi -pedantic模式下就会输出警告。这说明GCC完全能识别到表达式里包含非常量元素，只是不同语法位置的校验严格度不一样：静态存储期初始化的校验，长期绑定“是否可编译期求值”的判定，而不是“是否完全符合标准里常量表达式的语法定义”。
• 很多人对-ansi参数的作用存在误判，它远不是“100%严格遵循标准、禁用所有扩展”的开关。GCC里的-ansi本质等价于-std=c90，只会关闭少数和C90语法有直接冲突的扩展，不会禁用所有和标准语义有出入的宽松处理；哪怕叠加-pedantic参数，GCC也只会输出它认为需要提示的标准违规诊断，而静态初始化场景下的这种宽松处理，是GCC刻意保留的兼容行为，不在-pedantic的诊断范围内。

这是否属于GCC的Bug？ #

如果严格抠C90标准的字面要求，这个行为确实不符合“静态存储期对象初始化必须使用常量表达式”的约束规定，但它不属于常规意义上会导致程序错误的功能Bug：

• 这个行为是GCC维护团队明确知晓、且刻意保留了几十年的兼容设计，不是代码逻辑疏漏导致的意外。之所以一直不修正，是因为海量存量C代码依赖这种宽松写法，一旦严格按标准校验，会导致大量现存的开源、商业项目编译失败，兼容成本完全不可接受。
• 这个扩展本身不会引入违反开发者预期的问题：只要表达式能被GCC在编译期折叠为确定值，静态初始化的最终结果和手写符合标准的常量表达式的效果完全一致，不会产生未定义行为，也不会出现运行时逻辑错误。

如果你的项目需要严格贴合C90标准的常量表达式校验，Clang的默认校验逻辑更贴近标准文本的要求，这也是你测试时Clang会直接抛出错误的原因。

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