这在VC9中在警告级别4编译没有警告。为什么不认为这是编译器缺陷？ [英] this compiles without a warning in VC9 at warning level 4. Why would one NOT consider this a compiler defect?

问题描述

我看到一些发布的代码与超出范围的错误，使我不知道。我希望编译器为此代码生成警告（至少在最高级别）

  #pragma warning（push， 4）
 int main（）{
 int x [2]; 
 x [2] = 0; 
 return 0; 
} 
 #pragma warning（pop）
  

EDG编译器很好地说：

 sourceFile.cpp ，行3：警告：
下标超出范围
x [2] = 0; 
 ^ 
  

实际上EDG更多地说>

 sourceFile.cpp，第1行：警告：
无法识别#pragma 
 #pragma警告）
 ^ 
 
sourceFile.cpp，第4行：警告：
下标超出范围
x [2] = 0; 
 ^ 
 
sourceFile.cpp，第3行：警告：
设置变量x，但从未使用
 int x [2] 
 ^ 
 
sourceFile.cpp，第7行：警告：
无法识别#pragma 
 #pragma warning（pop）
  
 
 
 
但这不是我的问题。
 
 
 
我认为这个失败警告SERIOUS错误的遗漏在VC9，（更是如此，因为一个自动变量!!!!）。谁能给我一个严肃的理由改变主意？
解决方案
许多编译器有错误的选择这种事情。 / p> 
 
 
但是它是相当传统的，甚至适合C编译器默认情况下这样做。这有多种原因。
 
 
 
请记住， x [i] string[2] 或者 i [x] 你可以做 2 [string] 并得到相同的结果。尝试一下。这是因为 x [i] 定义为 *（x + i） 
 
 
 
 
由于指针运算是合法的，因此，很多相当体面的设计模式实际上取决于技术上的下标违反
 struct s {
 ...一堆东西... 
 int points [1]; // not really [1] 
}; 
 ... 
 struct s * p = malloc（sizeof（struct s）+ someNumber * sizeof（int））; 
 
有这样的代码运行在今天的所有地方...    更新 ：heh，这里是一个实际的 stackoverflow上的struct hack示例。
 
 
 
 
I saw some posted code with an out of range error on SO that made me wonder. I would expect a compiler to generate a warning (at the highest level at least) for this code 
#pragma warning(push,4)
int main(){
    int x[2];
    x[2]=0;     
    return 0;
}
#pragma warning(pop)
but it does not. 

The EDG compiler nicely says:
"sourceFile.cpp", line 3: warning:
          subscript out of range
          x[2]=0;
          ^
Actually EDG says bit more more(all of which are expected)
"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)
but that's not my question.

I consider this failure to warn a SERIOUS error of omission in VC9,(even more so since an auto variable!!!!). Can anyone give me a serious reason to change my mind?
解决方案
Many compilers have options to error out this kind of thing.

But it's quite traditional and even proper for C compilers to let this go by default. There are multiple reasons for this.

Remember that x[i] and i[x] are the same thing in C. You can even do "string"[2] OR you can do 2["string"] and get the same result. Try it. And this is because x[i] is defined as *(x + i) and once C is just doing pointer arithmetic and then derefing the result of the expression it's not in the compiler's domain to decide that it's going to work or not.
Given that pointer arithmetic is legal, lots of fairly-decent-for-their-day design patterns actually depend on technical subscript violations
struct s {
    ...bunch of stuff...
    int points[1]; // not really [1]
};
...
struct s *p = malloc(sizeof (struct s) + someNumber * sizeof(int));
There is code like this running today all over the place...     Update: heh, here is an actual example of the struct hack on stackoverflow.


                        
这篇关于这在VC9中在警告级别4编译没有警告。为什么不认为这是编译器缺陷？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！