GCC 编译器警告溢出答案

【问题标题】：GCC compiler warning overflowGCC 编译器警告溢出
【发布时间】：2013-05-22 18:10:55
【问题描述】：

编辑：我找到了一种使用 GCC 禁用来自第三方代码的警告的方法。看这篇文章就在这里：http://sphaleron.blogspot.se/2011/06/ignoring-gcc-warnings-on-per-file-basis.html 或者正如 bames53 帖子所说！

我刚刚升级了我的 GCC 编译器，突然间我收到了很多以前从未有过的警告。当我没有指定它应该是 Sint16 时，基本上每个人都是从 int 到 Sin16 的转换。

下面这个例子应该会抛出这样的警告：

int number = 6;
SDL_Rect rect = {number, number, number, number};

SDL_Rect 需要 Sint16 作为输入。无论如何，当我检查新警告时，我开始修复这些警告（因为为什么不呢？），令我惊讶的是，我从添加的 glew 文件中收到了 100 多个警告，以便能够更有效地使用 OpenGL 进行绘制。我没有计划仅仅为了修复警告而进入该代码。

你会怎么做？这有多重要？如果我不修复它们，是否有办法删除这些警告？

澄清：我总是修复更严重的警告，只是我的代码中的所有警告都是 Narrowing 警告（在 glew.c 中，它是“warning: 'variable' redeclared without dllimport attribute ：以前的 dllimport 忽略了 [-Wattributes]|"），我想知道修复这些问题有多重要，尤其是因为 glew 向我扔了一大堆。

【问题讨论】：

您可能不应该修复第三方标头中的警告。如果有的话，你可以将它报告给上游项目。但请注意，许多 OSS 项目不愿意修复任何编译器可以在任何架构中发出的任何编译器警告。这通常是一项不可能完成的任务。
您可以仅使用-Wno-attributes 选项（通过makefile、IDE 项目设置等）编译glew.c。如果您真的不关心该文件中的任何警告，请使用-w（注意这是小写w）
我该如何制作一个makefile？我不明白这个概念，因为我从未使用过。您认为我需要了解任何基本知识吗？还是我应该按照教程来创建一个？
对于一个简单的项目来说，创建一个 makefile 非常容易。您当前是否每次都手动调用编译？我会发布一个简短的答案。

标签： c++ gcc warnings glew

【解决方案1】：

您的项目应该始终没有警告。将编译器设置为将警告视为错误是鼓励开发人员保持无警告状态的好方法，尽管您必须注意并确保应该修复的警告不会因为在某个特定时刻更容易而被禁用.禁用警告应该需要审核。

任何无法修复的警告，因为它们位于第三方标题或其他地方，都应该被静音。否则，它们会在输出中添加噪音，从而隐藏您可以并且应该修复的警告。

如果警告的来源是相对本地化的，您可以仅针对源中的该位置禁用它：

// VC++
#pragma warning(push)
#pragma warning( disable : 4507 34)
#include <third_party_header.h>
#pragma warning(pop)

// clang
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wmultichar"
#include <third_party_header.h>
#pragma clang diagnostic pop

// GCC
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
#include <third_party_header.h>
#pragma GCC diagnostic pop

如果在许多地方出现警告并且您无法修复它们，因为它们是某种误报，您可以考虑使用编译器标志在整个项目（或可能是模块）中禁用警告

VC++：/wd4507

GCC/clang：-Wno-uninitialized

您还应该定期重新评估所有禁用的警告，以确保随着代码库和工具链的发展，禁用它们的原因仍然有效。还要寻找可以启用的新警告。

clang 有一个发现新警告的有用工具； -Weverything 标志。在 GCC 和 clang 上，-Wall 实际上只启用了编译器开发人员认为广泛适用且具有相对严格的误报要求的警告子集；基本上它只是一组很好的默认警告。 -Weverything 实际上启用编译器提供的所有警告。

与其对警告使用“加法”策略，在阅读编译器文档的地方，选择对你来说似乎不错的警告来启用，我更喜欢使用“减法”策略与-Weverything 结合@987654328 列表@标志。这样新的警告就会自动使用。请记住定期重新评估已禁用的警告，这样如果您以前认为没有用的警告得到改进，您就会看到改进并能够使用它。

【讨论】：

+1 很好的解决来自#includes of .h 文件的警告问题（我没有考虑过）。我认为仅在一个 .c 文件（您确实提到过）上禁用错误比在整个项目中执行此操作更可取。任何一种方法都应该没问题（#pragma 如果您可以修改源代码，否则标记）。

【解决方案2】：

你会怎么做？ 如果它们是我的源文件，我会修复它们，如果它们是我对开发没有影响/兴趣的外部代码，我会忽略它们。

这有多重要？ 这取决于您的优先级......但不修复它们可能不会使代码无法运行。但是，这是一种不好的做法，它可能会导致您在将来错过更重要的警告。您拥有的警告越多，带有警告的文件的开发越积极，清理它们就越有用。如果有充分的理由不修复它们（就像它是第 3 方代码......“太多的工作”本身并不是一个很好的理由），我会将相关代码移动到指定为警告负载的子项目中，所以我可以专注于自己的工作而无需警告。

如果我不修复它们，我有办法删除这些警告吗？ 听起来像降级编译器就可以了。

【讨论】：

也许可以为您的编译器找到 #pragma，该编译器仅在 3rd 方软件中禁用该特定警告。
我会修复我自己的警告（很简单，就像我说的只是缩小警告范围）并确保暂时忽略第三方代码。谢谢你的好答案！

【解决方案3】：

您可以使用make 编译仅 glew.c 和选项-Wno-attributes。如果您真的不关心该文件中的任何警告，请使用-w（注意这是小写的 w）。

下面是一个非常简单的makefile。请注意，每个命令行都以水平制表符 \t 开头，# 开始注释。

# 使用“make”或“make all”调用全部：main.o other.o glew.o g++ -o projectName main.o other.o glew.o -pedantic -Wall -Wextra -Werror main.o : main.c other.h glew.h g++ -c main.c -pedantic -Wall -Wextra -Werror 其他.o : 其他.c 其他.h g++ -c other.c -pedantic -Wall -Wextra -Werror glew.o : glew.c glew.h g++ -c glew.c -Wall -Wno-attributes # 或者，您可能需要以下内容之一： # g++ -c glew.c -Wno-attributes # g++ -c glew.c -w # 使用“make clean”删除可执行文件和中间文件干净的： rm 项目名称 *.o

您还可以做很多事情（请参阅the make manual）。甚至还有一些工具会自动为您创建 makefile。

【讨论】：