为什么GCC未对部分printf格式符与有符号类型不匹配场景输出警告？

该行为是GCC的有意设计，符合C/C++语言标准规范，不属于BUG。

根本原因：可变参数的默认整数提升规则 #

C/C++标准明确规定，printf这类可变参数函数的入参会触发默认参数提升：

• 所有宽度小于int的整数类型（包括signed char、short，无论有无符号），如果取值范围可被int完整覆盖，会自动提升为int类型传参，否则提升为unsigned int。
• 测试代码中signed char类型的-1、short类型的-1，传入printf时都会被提升为int类型的-1，和直接传入int类型-1的场景完全一致。

GCC printf格式警告的设计逻辑 #

• %u格式符期望接收unsigned int类型的参数，和int的内存宽度在所有主流平台完全一致，仅数值解释规则不同，不存在ABI层面的传参错误。
• 默认的-Wall -Wextra警告集不会对这类同宽度有符号/无符号类型不匹配的场景告警，因为大量合法代码会利用补码特性直接做有符号无符号的二进制转换，这类场景属于业务逻辑范畴而非明确的语法错误。如果需要触发这类警告，可以额外添加-Wformat-signedness编译选项，此时a、b、c三个函数的printf调用都会输出格式不匹配告警。

long/long long触发警告的原因 #

long、long long的内存宽度大于等于int，和%u期望的unsigned int宽度不匹配，属于明确的传参错误，会直接导致运行时输出结果异常，因此默认警告规则就会触发告警。

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