C/GCC 警告 - 编写一次并在各处测试？
我正在用 ANSI C 编写一个命令行程序来解析 Quake 2 地图文件以报告正在使用的实体和纹理的数量。我的开发机器是MacBook。我正在 OS X Snow Leopard（32 位）、Windows XP（32 位）和 Vista（64 位）以及 Ubuntu 9.10（32 位）上进行测试。
该代码在 OS X 和 GCC 4.2 上是完美的。其他平台则没有那么完美。
Visual Studio 2005 抱怨 main() 块中间的数组声明——直到那时数组的大小信息才可用——应该在顶部声明。通过在顶部声明一个指针并编写一个函数来创建数组来修复这个问题。
Windows 上的 Dev-C++ 和 GCC (3.4) 没有任何抱怨。
Windows 上的 Cygwin 和 GCC (4.4) 抱怨数组下标具有 char 类型。我添加了 (int) 强制转换来解决这个问题。
Ubuntu 和 GCC (4.4) 抱怨忽略 fread 的返回值。虽然我在其他地方读到我可能是 Ubuntu 打包 GCC 的方式上的一个 bug。在我使用 fread 的上下文中，这似乎可以安全地忽略。该警告仅与 -O3 标志一起出现。
除了 Visual Studio 2005 之外，我测试的所有编译器都是 GCC 的某个版本。追查所有这些错误和警告是一件非常痛苦的事情。到目前为止，我一直在 Makefile 中使用以下标志：
debug: -pedantic -Wall
release: -O3
是否应该使用一组 GCC 标志来捕获主要开发计算机上的所有错误？或者说，编写一次，到处测试是生活中的事实吗？
I'm writing a command line program in ANSI C to parse a Quake 2 map file to report how many entities and textures are being used. My development machine is MacBook. I'm testing on OS X Snow Leopard (32-bit), Windows XP (32-bit) and Vista (64-bit), and Ubuntu 9.10 (32-bit).
The code is flawless on the OS X and GCC 4.2. The other platforms, not so flawless.
Visual Studio 2005 complained about an array declaration in the middle of the main() block -- size info for the array isn't available until then--that should be declared at top. Fixed that by declaring a pointer at top and writing a function to create the array.
Dev-C++ and GCC (3.4) on Windows has no complaints.
Cygwin and GCC (4.4) on Windows complained about array subscript has type char. I added (int) casts to fix that.
Ubuntu and GCC (4.4) is complaining about ignoring the return value of fread. Although I read elsewhere that I might be a bug in the way Ubuntu packaged GCC. Seems like this one in the context I'm using fread in may be safe to ignore. The warning only appears with the -O3 flag.
Except for Visual Studio 2005, all the compilers that I tested with are some version of GCC. Chasing down all these errors and warnings is serious pain in the butt. Until now, I been using the following flags in my Makefile:
debug: -pedantic -Wall
release: -O3
Is there a set of GCC flags that I should be using to catch all the errors on my primary development machine? Or is write once and test everywhere a fact of life?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
令人恼火的是，Visual Studio 中的 C 方言（甚至是 Visual Studio 2010 的测试版！）已经很旧了，并且不支持所有 C99 功能，并且能够混合声明和可执行语句可能是其中最令人恼火的。最不邪恶的选择可能是在这个平台上编译为 C++，即使它需要重新安排代码以使其同时有效 C++ 和 C。
除此之外，正如 Ken 的评论所说，“一次编写测试” - 到处都是生活的事实”。 Lint 可以提供很好的帮助（正如 Chris 所写），但要找到语法和语义中的所有不兼容性，您确实需要在多个编译器和系统上编译和测试您的程序。这样做实际上可以帮助发现代码中的错误和问题，即使您并不打算在多个系统上实际运行该程序。
Irritatingly enough, the C dialect in Visual Studio (even the beta of Visual Studio 2010!) is old, and doesn't support all C99 features, and being able to mix declarations and executable statements is probably the most irritating of them all. The least evil option might be to compile as C++ instead on this platform, even if it requires some re-arranging of your code to make it both valid C++ and C.
Other than that, as Ken's comment said, "write-once-test-everywhere is a fact of life". Lint can be a good help (as Chris wrote), but to find all the incompatibilities in syntax and semantics you really need to compile and test your program on several compilers and systems. Doing this can actually help find errors and problems in your code, even if you don't intend to actually run the program on more than one system.
给自己准备一份 Lint 的副本。 Lint 是一个静态分析工具，几乎涵盖了所有编译器错误和警告等等。对于经常编写针对不同平台和编译器的代码的人来说，确保代码通过 Lint 是让代码在所有编译器上运行的一个非常好的晴雨表。
近似 lint 的最佳 gcc 标志集类似于：
我也经常使用
if I am going to be writing 64-bit code because many compilers complain that long long is not a c++ type.
*编辑：修复命令行选项中的复制和粘贴错误
Get yourself a copy of Lint. Lint is a static analysis tool that will pretty much cover the full range of compiler errors and warning and then some. As someone who frequently writes code targeting different platforms and compilers ensuring that the code passes through Lint is a pretty good barometer for getting the code to run across all compilers.
The best set of gcc flags to approximate lint is something like:
I also often use
if I am going to be writing 64-bit code because many compilers complain that long long is not a c++ type.
*Edit: Fixing copy and paste error in command line options
添加
-ansi到混合中。规范集是-ansi -pedantic -Wall。也就是说，您可能会发现 MSVC 的其他怪癖，因为它是一个完全不同的编译器，有自己的警告 - 所以您可能也必须调整它的选项。
Add
-ansito the mix. The canonical set is-ansi -pedantic -Wall.That said, you will probably find other quirks with MSVC, because it's a different compiler altogether, with its own warnings - so you might have to tweak its options too.
使用 -Wall 和 Lint 可以节省大量时间，因为它们将帮助您更好地理解代码。重新编写代码以最大程度地减少安全忽略警告。您将不太可能为难以重现的运行时故障而苦恼。此外，无论谁维护您的代码，都会发现更改起来更容易。
当您使用 Visual Studio 时，请探索 Lint 之类工具的编译选项。我忘记它们在哪里，它们会减慢你的构建速度，但它们很有帮助。
You can save much time by using -Wall and Lint, because they will help you understand your code better. Rework your code to minimize the safe-to-ignore warnings. You will be less likely to agonize over a hard to reproduce run-time failure. Also, whoever maintains your code will find it easier to make changes.
When you are using Visual Studio, explore the compile options for Lint like tools. I forget where they are, and they slow down your build, but they are helpful.