非固定的警告迟早会导致代码中的错误。

例如，调试分段错误需要程序员追踪错误的根源(原因)，它通常位于代码中比最终导致分段错误的行更前面的位置。

很典型的情况是，导致错误的行是编译器发出警告而你忽略的行，而导致分段错误的行是最终抛出错误的行。

修复警告就等于修复了问题……一个经典的!

以上的演示…考虑下面的代码:

#include <stdio.h>

int main(void) {
  char* str = "Hello, World!!";
  int idx;

  // Colossal amount of code here, irrelevant to 'idx'

  printf("%c\n", str[idx]);

  return 0;
}

当使用传递给GCC的"Wextra"标志进行编译时，给出:

main.c: In function 'main':
main.c:9:21: warning: 'idx' is used uninitialized in this function [-Wuninitialized]
    9 |   printf("%c\n", str[idx]);
      |                     ^

我可以忽略它，然后执行代码……然后我就会看到一个“重大”分割错误，就像我的IP伊壁鸠鲁教授曾经说过的那样:

段错误

为了在现实场景中调试这一点，人们将从导致分段错误的行开始，并试图跟踪原因的根源是什么……他们将不得不在那里的大量代码中搜索i和str发生了什么……

直到有一天，他们发现idx使用时没有初始化，因此它有一个垃圾值，这导致索引字符串(方式)超出其界限，从而导致分割错误。

如果他们没有忽视这个警告，他们就会立即发现这个漏洞!

警告包含了一些最熟练的c++开发人员可以放入应用程序中的最佳建议。他们值得留在身边。

C++, being a Turing complete language, has plenty of cases where the compiler must simply trust that you knew what you are doing. However, there are many cases where the compiler can realize that you probably did not intend to write what you wrote. A classic example is printf() codes which don't match the arguments, or std::strings passed to printf (not that that ever happens to me!). In these cases, the code you wrote is not an error. It is a valid C++ expression with a valid interpretation for the compiler to act on. But the compiler has a strong hunch that you simply overlooked something which is easy for a modern compiler to detect. These are warnings. They are things that are obvious to a compiler, using all the strict rules of C++ at its disposal, that you might have overlooked.

关闭或忽略警告，就像选择忽略那些比你更有经验的人的免费建议。这是一个傲慢的教训，当你飞得离太阳太近，翅膀融化了，或者发生记忆损坏错误时，这个教训就结束了。在这两者之间，我愿意随时从天上掉下来!

“将警告视为错误”是这一哲学的极端版本。这里的想法是解决编译器给您的每个警告——您听取每个免费建议并执行它。这对你来说是否是一个好的开发模式取决于你的团队以及你所开发的产品类型。这是僧侣可能有的苦行方式。对一些人来说，效果很好。对另一些人来说，则不然。

在我的许多应用程序中，我们不将警告视为错误。我们这样做是因为这些特定的应用程序需要在多个平台上编译，使用多个不同年代的编译器。有时我们会发现，如果在一个平台上修复一个警告，而不将其转化为另一个平台上的警告，实际上是不可能的。所以我们只是小心行事。我们尊重警告，但我们不会为它们竭尽全力。

作为使用遗留嵌入式C代码的人，启用编译器警告有助于在提出修复时显示许多弱点和需要调查的领域。在GCC中，使用-Wall和-Wextra甚至-Wshadow变得至关重要。我不打算一一列举每一个危险，但我将列出一些已经出现的有助于显示代码问题的危险。

变量被落下

这可以很容易地指出未完成的工作和可能没有使用所有传递变量的区域，这可能是一个问题。让我们来看看一个简单的函数，它可能会触发这个:

int foo(int a, int b)
{
   int c = 0;

   if (a > 0)
   {
        return a;
   }
   return 0;
}

在没有-Wall或-Wextra的情况下编译它不会返回任何问题。-Wall会告诉你c从来不用:

foo.c:在函数' foo '中:

Foo.c:9:20:警告:未使用的变量' c ' (-Wunused-variable)

wextra还会告诉你参数b什么都不做:

foo.c:在函数' foo '中:

Foo.c:9:20:警告:未使用的变量' c ' (-Wunused-variable)

foo.c:7:20:警告:未使用参数' b ' [-Wunused-parameter] int foo(int a, int b)

全局变量阴影

这一点有点难，直到使用-Wshadow才显示出来。让我们修改上面的示例，只添加一个，但是刚好有一个全局变量和一个局部变量同名，这在尝试使用两者时造成了很多混乱。

int c = 7;

int foo(int a, int b)
{
   int c = a + b;
   return c;
}

当打开-Wshadow时，很容易发现这个问题。

Foo.c:11:9:警告:声明' c '隐藏全局声明 (-Wshadow) Foo.c:1:5:注意:阴影声明在这里

格式字符串

这在GCC中不需要任何额外的标志，但在过去它仍然是问题的根源。一个简单的函数试图打印数据，但有格式化错误，可能是这样的:

void foo(const char * str)
{
    printf("str = %d\n", str);
}

这不会打印字符串，因为格式化标志是错误的，GCC会很高兴地告诉你这可能不是你想要的:

foo.c:在函数' foo '中:

Foo.c:10:12:警告:格式' %d '期望 参数类型为' int '，但参数2的类型为' const char * ' (-Wformat =)

这只是编译器可以为您进行双重检查的许多事情中的三件。还有很多其他的方法，比如使用未初始化的变量。

处理警告不仅能写出更好的代码，还能让你成为更好的程序员。警告会告诉你一些今天对你来说微不足道的事情，但总有一天坏习惯会回来咬你的头。

使用正确的类型，返回该值，计算该返回值。花点时间思考“在这种情况下，这真的是正确的类型吗?”“我需要把这个还回去吗?”最重要的是;“这个代码在未来10年里还能移植吗?”

首先要养成编写无警告代码的习惯。

这是C的一个具体答案，以及为什么这对C来说比其他任何东西都重要。

#include <stdio.h>

int main()
{
   FILE *fp = "some string";
}

此代码编译时带有警告。地球上几乎所有其他语言(除了汇编语言)中存在的和应该存在的错误都是C语言中的警告。C语言中的警告几乎都是伪装的错误。警告应该被修正，而不是被压制。

对于GCC，我们执行GCC -Wall -Werror。

这也是微软一些不安全API警告引起高度不满的原因。大多数编写C语言的人已经学会了将警告视为错误的艰难方法，而这些东西出现的不是同一种东西，需要不可移植的修复。

你应该总是启用编译器警告，因为编译器经常会告诉你代码哪里出了问题。为此，您将-Wall -Wextra传递给编译器。

您通常应该将警告视为错误，因为警告通常表示您的代码有问题。然而，通常很容易忽略这些错误。因此，将它们视为错误将导致构建失败，因此您不能忽略这些错误。若要将警告视为错误，请将-Werror传递给编译器。