C的推荐gcc警告选项

Question

C的推荐gcc警告选项

除了-Wall之外,其他人发现的警告有用吗？

http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Warning-Options.html

Answer 1

我经常使用:

    gcc -m64 -std=c99 -pedantic -Wall -Wshadow -Wpointer-arith -Wcast-qual \
        -Wstrict-prototypes -Wmissing-prototypes

Run Code Online (Sandbox Code Playgroud)

这个集合对于那些不习惯它的人来说很有用(我的代码是第一次用这些标志编译的人); 它很少给我一个问题(虽然-Wcast-qual偶尔会令人讨厌).

根据gcc doc,-O2是最好发现警告的.我不确定-O3是否暗示-O2或允许生成更多警告. (3认同)
如果您不在64位环境中,请跳过-m64. (3认同)
另外,添加`-O3`或类似的东西是个好主意; 只有在优化代码时才会生成警告. (2认同)
同时使用“-m32”和“-m64”（当然，在单独的运行中）可以更好地防止使用“printf()”和“scaf()”转换规范时出现的各种错误。 (2认同)

Answer 2

pmg*_*pmg 39

截至2011-09-01,使用gcc版本4.6.1

我目前的"发展"别名

gcc -std=c89 -pedantic -Wall \
    -Wno-missing-braces -Wextra -Wno-missing-field-initializers -Wformat=2 \
    -Wswitch-default -Wswitch-enum -Wcast-align -Wpointer-arith \
    -Wbad-function-cast -Wstrict-overflow=5 -Wstrict-prototypes -Winline \
    -Wundef -Wnested-externs -Wcast-qual -Wshadow -Wunreachable-code \
    -Wlogical-op -Wfloat-equal -Wstrict-aliasing=2 -Wredundant-decls \
    -Wold-style-definition -Werror \
    -ggdb3 \
    -O0 \
    -fno-omit-frame-pointer -ffloat-store -fno-common -fstrict-aliasing \
    -lm

"释放"别名

gcc -std=c89 -pedantic -O3 -DNDEBUG -flto -lm

截至2009-11-03

别的"发展"

gcc -Wall -Wextra -Wformat=2 -Wswitch-default -Wcast-align -Wpointer-arith \
    -Wbad-function-cast -Wstrict-prototypes -Winline -Wundef -Wnested-externs \
    -Wcast-qual -Wshadow -Wwrite-strings -Wconversion -Wunreachable-code \
    -Wstrict-aliasing=2 -ffloat-store -fno-common -fstrict-aliasing \
    -lm -std=c89 -pedantic -O0 -ggdb3 -pg --coverage

"释放"别名

gcc -lm -std=c89 -pedantic -O3 -DNDEBUG --combine -fwhole-program -funroll-loops

需要注意的是`-Wstrict走样= 2`实际上降低了`-Wstrict走样的警告级别= 3`通过`-Wall`暗示,至少在最近版本的gcc. (4认同)

Answer 3

Jes*_*erE 15

我喜欢 - 错误.保持代码警告免费.

没有-Werror所有其他警告选项毫无意义.将警告视为错误几乎是确保警告得到解决的唯一方法.如果他们只是警告,开发人员可能会决定留下一个,因为他确定它是无效的.它甚至可能是真的,但下一个开发人员不会修复他引入的警告,因为他没有在所有其他人之间看到它,或者因为它只是一个警告. (21认同)
我理解为什么这很诱人,但是当你有一份工作副本时,你更有可能保留它,因为"它有效".在企业环境中,这种风险甚至更高,您必须说服您的老板给您一些时间来修复警告. (9认同)
我不同意Kristof,因为很多时候,我宁愿只是先编译一个工作副本,然后_then_解决错误. (6认同)
如果您使用开源软件,那么在您的构建中默认不使用`-Werror`它会使您使用不同编译器版本的打包程序变得烦恼,因为警告随编译器版本而变化,有时代码对您没有警告会发出警告对于其他人,然后他们必须深入你的构建系统来关闭它. (3认同)
我认为摆脱`#warning`是使用`-Werror`的良好副作用. (2认同)
强迫打包人员修改您的代码以使其在他们的系统上没有警告地构建是要求诸如 Debian SSL 错误 [1] 之类的错误。允许编译带有警告的代码有很多有用的理由，如果您的开发人员懒得在签入工作之前修复警告，那么您肯定会遇到比 -Werror 可以修复的更大的质量控制问题。[1] https://www.schneier.com/blog/archives/2008/05/random_number_b.html (2认同)

Answer 4

Tom*_*Tom 15

我从C++开始,所以当我切换到学习CI时,确保是肛门:

-fmessage-length=0
-ansi -pedantic -std=c99
-Werror
-Wall
-Wextra
-Wwrite-strings
-Winit-self
-Wcast-align
-Wcast-qual
-Wpointer-arith
-Wstrict-aliasing
-Wformat=2
-Wmissing-declarations
-Wmissing-include-dirs
-Wno-unused-parameter
-Wuninitialized
-Wold-style-definition
-Wstrict-prototypes
-Wmissing-prototypes

你能同时使用-ansi -pedantic -std = c99吗？是不是-ansi与c89大致相同？如果是这样,它如何与c99标志一起使用？ (5认同)
@Johan - 你可以,而且它实际上并不是必需的,因为我最近发现了.-ansi暗示-std = <default>,所以你真的可以说-std = c99 -pedantic并获得完全相同的效果.我确实倾向于使用它,只是为了文档效果.我觉得它的内容是"这个代码是ANSI标准的(迂腐!),使用标准的C99." 之后通常会出现-Wno-long-long或类似...... ANSI标准的任何例外情况. (2认同)

Answer 5

Dev*_*lar 9

获取该手册使用的GCC的版本,发现所有的警告选项可用,然后关闭只有那些您有一个令人信服的理由这样做.(例如,不可修改的第三方标题会给你很多警告.)记录这些原因.(在Makefile中或您设置这些选项的任何位置.)在常规intervalls 和每次升级编译器时查看设置.

编译器是你的朋友.警告是你的朋友.给编译器尽可能多的机会告诉您潜在的问题.

仅供参考，该手册没有提供单一的综合警告列表。但是，您可以在[此处](https://github.com/barro/compiler-warnings)找到此类列表，以及用于生成它们的工具。 (3认同)

Answer 6

Nil*_*nck 5

我也用:

-Wstrict溢出= 5

如果我编写依赖于整数溢出行为的代码,可以捕获可能出现的那些令人讨厌的错误.

和:

-Wextra

这使得一些选项也很好.大多数都是针对C++的.

-Wextra似乎是-W的新名称(仍然支持) (4认同)

Answer 7

Tom*_*ter 1

这将是选项-pedantic-errors。

@unexist 尝试安装 `clang` （LLVM 项目的 C 编译器），然后使用 `-Weverything` 进行编译，你会发现编译真的变得多么有趣（有些警告完全疯狂，但它们在技术上是正确的））。 (2认同)

归档时间：	17 年，2 月前
查看次数：	31261 次
最近记录：	14 年，3 月前