在 VC9 中编译时不会出现警告级别 4 的警告。为什么人们不认为这是一种编译器缺陷呢？

Question

我看到一些发布的代码有超出范围的错误，这让我感到好奇。我希望编译器会为此代码生成警告（至少在最高级别），

#pragma warning(push,4)
int main(){
    int x[2];
    x[2]=0;     
    return 0;
}
#pragma warning(pop)

但事实并非如此。

EDG 编译器很好地表示：

"sourceFile.cpp", line 3: warning:
          subscript out of range
          x[2]=0;
          ^

实际上 EDG 说得更多（所有这些都是预期的），

"sourceFile.cpp", line 1: warning: 
          unrecognized #pragma
  #pragma warning(push,4)
          ^

"sourceFile.cpp", line 4: warning: 
          subscript out of range
      x[2]=0;     
      ^

"sourceFile.cpp", line 3: warning: 
          variable "x" was set but never used
      int x[2];
          ^

"sourceFile.cpp", line 7: warning: 
          unrecognized #pragma
  #pragma warning(pop)

但这不是我的问题。

我认为这个失败警告了 VC9 中的严重遗漏错误（自从使用自动变量以来更是如此！！！）。谁能给我一个改变主意的严肃理由？

Answer 1

许多编译器都有选项来错误地处理此类事情。

但对于 C 编译器来说，默认放弃这一点是非常传统的，甚至是正确的。造成这种情况的原因有很多。

1. 请记住，x[i] 和 i[x] 在 C 中是相同的。您甚至可以执行 "string"[2] 或者您可以执行 2["string"] 并获得相同的结果。尝试一下。这是因为 x[i] 被定义为 *(x + i) 并且一旦 C 只是进行指针算术，然后取消引用它不在其中的表达式的结果编译器的域来决定它是否能够工作。

2. 鉴于指针算术是合法的，许多当时相当不错的设计模式实际上依赖于技术下标违规

   结构体{
       ...一堆东西...
       整数点[1]； // 并非如此 [1]
   };
   ...
   struct s *p = malloc(sizeof (struct s) + someNumber * sizeof(int));
   
   
   今天到处都在运行这样的代码...    更新：嘿，这是一个实际的stackoverflow 上的 struct hack 示例。

Answer 2

编译器不需要对未定义的行为发出警告（即使是像这样的“严重”行为）。许多编译器倾向于检查不同的行为集。我认为如果您有 VSTS，则可以启用一些额外的安全检查，因此这可能会被捕获。此外，编译器可以插入运行时检查来捕获此内存覆盖（可能用于调试版本），因此您应该确保启用了这些检查。

Answer 3

虽然给出的示例非常简单，但要在编译期间做好静态分析通常需要大量代码并减慢编译速度（简单的实现意味着再次通过 AST）。

在一种经常因编译缓慢而受到谴责的语言中。

让你变得愚蠢是 C++ 的重要组成部分。试图让你摆脱困境的编译器很好，但那是肉汁。

FWIW：g++ -Wall 也无法发出警告。

Answer 4

对源执行静态代码分析时会发出此警告。不过，静态代码分析不是编译器规范的一部分（至少据我所知），并且是由单独的工具完成的。

以下是C/C++ 代码分析的概述。以及该工具涵盖的警告列表。

Answer 5

它没有对此发出警告的原因是它很少有用。查看您的代码：

int main(){
    int x[2];
    x[2]=0;     
    return 0;
}

我们看到在这种情况下编译器能够发出警告，但这只是因为：

• 数组尚未衰减为指针 - 换句话说，大小信息是仍然可用，并且
• 您正在使用编译时常量表达式来索引数组。

在大多数现实世界的代码中，这两个条件都不成立。数组几乎总是一个指针，在这种情况下编译器根本没有大小信息。同样，您经常使用运行时确定的值来索引数组。再说一遍，如果你这样做，编译器将无法确定你是否会超出范围。

换句话说，虽然是的，编译器在这种情况下可能会发出警告，我同意，它也可能会发出警告，但它实际上只会对像这样的非常简单的玩具示例有帮助。

如果代码看起来像这样：

void foo(int* x){
    x[2]=0;     
}

或这样：

void foo(int i){
    int x[2];
    x[i]=0;
}

编译器将无能为力。这些情况更为常见。正如其他人已经提到的，C++ 编译器的最大问题之一是它们已经慢得要命。他们必须检查的每个新警告都会增加更多的开销。那么，是否值得为基本上只发生在像这样的小玩具示例中的错误添加警告呢？

至于为什么你的反应如此糟糕，也许答案就在你的问题中：

我认为这种失败未能警告 VC9 中的严重遗漏错误，（自从使用自动变量**!!!!!!** 以来更是如此）。谁能给我一个改变主意的严肃理由？

减少加载的语言。坚持使用一个感叹号。如果你听起来像是要烧断保险丝，那么人们会认为你愤怒，然后他们会告诉你你反应过度，你应该闭嘴。

Answer 6

因为，编译器不是你的保姆。

Answer 7

有几件事可能值得注意：

1. 除非您关闭所有优化，否则编译结果将一无所获。内存根本不会被写入 - 你可能还写过：

   #pragma warning(push,4)
   int main(){
       返回0；
   }
   #pragma 警告（弹出）
   

2. 正如其他地方提到的，进行这样的分析很困难（如不可计算的尝试解决停止问题）。在进行优化时，只在分析容易的情况下进行优化是可以的。当您寻找警告时，需要在能够找到简单案例和让人们依赖警告之间进行权衡。什么时候可以停止发出警告？是的，通过常量偏移量访问的本地声明的变量是微不足道的 - 但由于微不足道，它也就不那么重要了。如果访问是在普通内联函数中怎么办？或者如果访问处于具有常量边界的 for 循环中？这些都很容易查找，但它们各自代表了一整套新的测试、可能的回归等...几乎没有什么好处（如果有的话）。

我并不是说这个警告没有用——它只是不像你想象的那么明确。