C-Journey

主题

正常

警告旗标进阶：从 -Wall -Wextra 到 -Werror -Wpedantic ​

引言：编译器想帮你，是你没让它开口 ​

很多人对编译器的态度是「只要没报 error，能编过就行」——至于那一屏飘过去的 warning:，压根没当回事。等程序在运行时崩出一个诡异的值，回头一看，那个 bug 编译器早就用一条 warning 跟你说过，只是你没开那个旗标、或者没看它。

这一章我们把 gcc 最常用的几个警告旗标挨个真跑一遍，看它们各自抓什么、又各自漏什么。读完你会明白为什么本课程把 -Wall -Wextra 当标配、把 -Werror 在 CI 里当硬门、还要拿 -Wpedantic 区分「能编过」和「真的是标准 C」——以及为什么哪怕全开，编译器还是会漏，那部分得留给第 11 章的 sanitizer。

先说一句最重要的、也最容易被名字骗的：-Wall 并不是「所有警告」。Wall 里的 all 是历史遗留的营销，它只开「一组 gcc 认为值得默认开的警告」，还有大量警告——有些相当要命——得靠 -Wextra 和专门的 -Wxxx 才会亮。下面我们就用真例子拆开看。

-Wall 不够：-Wextra 补的那一刀 ​

先看一个 -Wall 完全没声音、但 -Wextra 一抓一个准的例子：

c
int f(int x, int y) {
    return x;
} /* y 根本没用上 */

只开 -Wall，编译器一声不吭：

text
$ gcc -std=c11 -Wall -c d1.c -o d1.o
$                          ← 空,没任何 warning

加上 -Wextra，立刻现形：

text
$ gcc -std=c11 -Wall -Wextra -c d1.c -o d1.o
d1.c: In function 'f':
d1.c:1:18: warning: unused parameter 'y' [-Wunused-parameter]

「未使用的参数」算不上致命，但 -Wextra 还会帮你抓很多 -Wall 漏掉的东西（比如某些空语句、签名不一致的松散检查）。所以只开 -Wall 是不够的，本课程从第 1 章起就一直是 -Wall -Wextra 一起开。

再说一个 -Wall 本来就能抓、而且是真坑的典型——把 == 写成 =：

c
int g(int x) {
    if (x = 5)
        return 1;
    return 0;
} /* 本来想写 x == 5 */
text
$ gcc -std=c11 -Wall -c d2.c -o d2.o
d2.c:1:20: warning: suggest parentheses around assignment used as truth value [-Wparentheses]

-Wparentheses（包含在 -Wall 里）识破了「你在条件里写的是赋值 = 而不是比较 ==」，给你一句提醒。这种笔误要是没被旗标拦下，运行时表现为「循环永远进 / 永远不进」，能让人查到怀疑人生。

-Werror：让警告直接挡住构建 ​

光报警告，人还是会忽略。-Werror 把所有警告升级成错误——有 warning 就别想编过：

text
$ gcc -std=c11 -Wall -Werror -c d2.c -o d2.o
d2.c:1:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

注意原来的 warning: 变成了 error:，编译直接失败。本仓库的 CI 就是这么用 -Werror 当硬门的：你提交的代码要是有 warning，CI 当场红给你看。

不过 -Werror 也有它的麻烦：升级编译器之后，新版 gcc 经常会新增一类警告，你原来干干净净的代码突然就开始报新 warning、被 -Werror 一挡，构建莫名其妙就红了。所以工程里常见的做法是「整体开 -Werror，但对个别暂时没法处理的警告用 -Wno-xxx 局部豁免」（比如 -Wno-unused-parameter），或者用 -Werror=xxx 只把特定警告升级成错误、其余还停留在 warning。这是个「严」与「不折腾」之间的工程取舍。

-Wpedantic：「能编过」不等于「标准 C」 ​

gcc 默认是挺纵容的——哪怕你指定了 -std=c89，它还是会悄悄放行很多 C89 之后才有的、或者根本是 GNU 扩展的写法。来看 long long（C99 才有，C89 里没有）：

c
long long x = 0; /* C99 起,C89 没有这个类型 */
text
$ gcc -std=c89 -c d4.c -o d4.o
$                          ← 静默通过!gcc 没吭声
$ gcc -std=c89 -Wpedantic -c d4.c -o d4.o
d4.c:1:6: warning: ISO C90 does not support 'long long' [-Wlong-long]

只写 -std=c89，gcc 默默接受了 long long——你以为自己写的是「严格 C89」，其实混进了 C99 的东西，换一个较真的编译器（或加 -pedantic-errors）就过不去。加上 -Wpedantic，它才如实告诉你「这玩意儿 ISO C90 不支持」。

这一点和第 1 章那条「-std=gnuXX 默默开 GNU 扩展」是一回事：gcc 的默认姿态是「能让你过就让你过」，而 -Wpedantic 就是逼它「严格按标准挑刺」。本课程示例一律显式 -std=cXX，需要严格时配 -Wpedantic，目的是让代码换编译器（尤其换到 clang、或者未来的新 gcc）时不被默认纵容坑到。

-Wconversion：连 -Wextra 都不抓的数据丢失 ​

下面这种「把大类型塞进小类型」的隐式截断，-Wall -Wextra 全开了也未必理你：

c
int narrow(long big) {
    return big;
} /* long 截成 int,可能丢数据 */
text
$ gcc -std=c11 -Wall -Wextra -c d5.c -o d5.o
$                          ← 空,没 warning
$ gcc -std=c11 -Wall -Wextra -Wconversion -c d5.c -o d5.o
d5.c:1:31: warning: conversion from 'long int' to 'int' may change value [-Wconversion]

-Wconversion 才会提醒你「这次 long → int 可能丢数据」。这类截断在嵌入式/协议解析里特别常见（把 uint32_t 塞进 uint16_t 之类），是潜伏的 bug 源。-Wconversion 比较激进、在一些老代码上会刷一大片，所以没进标配，但写新代码时值得一开。

-Wuninitialized：警告是有盲区的，别太信它 ​

读未初始化的变量是 UB，-Wuninitialized（-Wall 含）本来该抓。简单的直读它确实抓得到——而且这台 gcc 16 上 -O0、-O2 都抓：

c
int use_u(void) {
    int u;
    return u;
} /* 直接读未初始化 */
text
$ gcc -std=c11 -Wall -O0 -c d6.c -o d6.o
d6.c:1:33: warning: 'u' is used uninitialized [-Wuninitialized]
$ gcc -std=c11 -Wall -O2 -c d6.c -o d6.o
d6.c:1:33: warning: 'u' is used uninitialized [-Wuninitialized]

但把读取藏进一个条件分支，gcc 16 在 -O0 和 -O2 都没报：

c
int cond(int flag) {
    int u;
    if (flag)
        u = 10; /* flag==0 时 u 没被赋值 */
    return u;   /* 这条路径上读的是未初始化的 u */
}
text
$ gcc -std=c11 -Wall -O0 -c d7.c -o d7.o   ← 空
$ gcc -std=c11 -Wall -O2 -c d7.c -o d7.o   ← 也空!两个都没报

这就是 -Wuninitialized（其实也是所有警告旗标）的真相：它做的是 best-effort 的静态分析，能力有限、有明显盲区。-Wuninitialized 尤其依赖优化器的数据流分析（所以老资料会说它「只在开了 -O 才灵」），但即便开了 -O2，这种「某条路径才未初始化」的情形它照样漏。结论很硬：「没报警告」绝不等于「没有 UB」——这正是为什么第 11 章我们要上 sanitizer，靠运行期的真插桩来兜这个底。

本课程的标配旗标集 ​

把前面几条收拢成一套可以直接抄进 Makefile/CMake 的标配：日常编译至少 -std=c11 -Wall -Wextra；CI 里加 -Werror 当硬门，必要时 -Wpedantic 查严格标准符合性；写新库时再叠加 -Wconversion、-Wshadow 这些更细的。这套不是教条，是踩过「只开 -Wall 结果漏了一片」的坑之后攒出来的下限。

小结 ​

一句话：-Wall 名字唬人但不是「所有警告」，-Wextra 是它的必备搭档；-Werror 把警告变成 CI 的硬门，但升级编译器时新警告会让它突然变红，要会用 -Wno-xxx 局部豁免；-Wpedantic 区分「能编过」和「真的是标准 C」，逼 gcc 别再纵容非标写法；-Wconversion 抓 -Wall/-Wextra 都不管的数据截断；而 -Wuninitialized 即便开了 -O2 也有盲区——条件分支里的未初始化读取它一声不吭，所以警告只是 best-effort，真正的兜底是第 11 章的 sanitizer，别拿「没 warning」当「没 bug」。

下一章我们把 -std 各档、-O0..-O3 优化级别、-g 调试信息一起系统讲透，顺便解释为什么这一章好几个旗标（尤其 -Wuninitialized）的行为会和 -O 级别绑在一起。

参考资源 ​

  • man gcc 的 Warning Options 一节（-Wall/-Wextra 各自到底开哪些子警告的完整清单）
  • GCC 手册：-Wpedantic / -pedantic-errors、-Wconversion、-Wshadow、-Werror=...、-Wno-...
  • ISO/IEC 9899：long long 自 C99 引入（-Wlong-long 在 C89 模式下报警的依据）
  • 本仓库 .github/workflows/ci.yml（-Werror 作为 CI 硬门的真实写法，第 17 章逐行拆）