为什么没有这种明显的无限递归给出一个编译器警告？ [英] Why doesn't this obvious infinite recursion give a compiler warning?

问题描述

许多个月后，我不得不修复了导致了一些问题的一些代码。该代码看起来基本上是这样的：

Many months back, I had to fix up some code that caused some problems. The code looked basically like this:

INT badFun（）{返回badFun（）; }

这很明显，即使在我与（4Test在SilkTest中）工作的高级语言导致堆栈溢出。有没有办法这段代码可以被看作是有益的。问题的第一个迹象是看到剧本完成之后的警告，但没有编译错误或警告。奇怪的是，我试图在C ++，C＃和Python编写程序具有相同的结构，并且所有的编译/没有语法错误或警告的解释，甚至通过有在所有情况下运行时错误。我甚至没有看到任何这些案件的任何警告。为什么不是这被视为默认情况下可能出现的问题？

This obviously caused a stack overflow even in the high level language I was working with (4Test in SilkTest). There's no way this code could be seen as beneficial. The first sign of problems were warnings seen after the script finished, but no compile errors or warnings. Curiously, I tried writing programs in C++, C# and Python with the same structure, and all of them compiled/interpreted with no syntax errors or warnings, even through there were runtime errors in all cases. I didn't even see any warnings in any of these cases. Why isn't this seen as a possible problem by default?

编辑：我试着在这三种语言编写函数等价，所以我说的那些功能的标签。我更感兴趣的是整体的原因，这样的代码获得通过，没有警告。请重新标记，如果有必要

I tried writing the equivalent of that function in all three languages, so I added those function tags. I'm more interested in overall reasons why code like this gets through with no warnings. Please retag if necessary.

推荐答案

这里的交易：编译器警告是的功能的。功能需要的工作的和精力是有限的数量。 （它可能用美元来衡量，也可能在几小时有人愿意给一个开源项目的数量来衡量，但我向你保证，它是有限的。）

Here's the deal: compiler warnings are features. Features require effort, and effort is a finite quantity. (It might be measured in dollars or it might be measured in the number of hours someone is willing to give to an open source project, but I assure you, it is finite.)

因此，我们必须预算的努力。我们花设计，实施，测试和调试功能每一个小时一个小时，我们可以花做别的事情。因此，我们非常谨慎决定哪些功能补充。

Therefore we have to budget that effort. Every hour we spend designing, implementing, testing and debugging a feature is an hour we could have spent doing something else. Therefore we are very careful about deciding what features to add.

这是所有功能实现。警告有特殊的额外关注。警告具有为大约代码有如下特点：

That's true of all features. Warnings have special additional concerns. A warning has to be about code that has the following characteristics:

• 法律。显然，代码必须是合法的;如果它是不合法的，然后它不是摆在首位的警告，它的错误。


• 几乎可以肯定是错误的。警告您有关正确的，理想的代码的警告是一个糟糕的警告。 （此外，如果代码的是的正确的，应该有编写代码，使得警告消失的方式。）


• Inobvious。警告应该告诉你的是微妙的，而不是明显的错误。


• 适合进行分析。一些警告是根本不可能的;需要编译器来解决停机问题，例如一个警告，是不会发生的，因为这是不可能的。


• 不可能被其他形式的测试捕获。

• Legal. Obviously the code has to be legal; if it is not legal then its not a warning in the first place, its an error.
• Almost certainly wrong. A warning that warns you about correct, desirable code is a bad warning. (Also, if the code is correct, there should be a way to write the code such that the warning goes away.)
• Inobvious. Warnings should tell you about mistakes that are subtle, rather than obvious.
• Amenable to analysis. Some warnings are simply impossible; a warning that requires the compiler to solve The Halting Problem for example, is not going to happen since that is impossible.
• Unlikely to be caught by other forms of testing.

在您的具体的例子，我们可以看到其中的一些条件得到满足。该代码是合法的，而且几乎可以肯定是错误的。但它是inobvious？有人可以很容易地查看代码，看看它是一个无限递归;警告不会有什么帮助。它是经得起分析？你给的简单的例子是，但要找到无限递归的一般问题就等于解决停机问题。它是不太可能被其他形式的测试被抓？号你在你的测试用例运行该代码的那一刻，你会得到一个异常，告诉你恰恰是错误的。

In your specific example, we see that some of these conditions are met. The code is legal, and almost certainly wrong. But is it inobvious? Someone can easily look at the code and see that it is an infinite recursion; the warning does not help much. Is it amenable to analysis? The trivial example you give is, but the general problem of finding unbounded recursions is equivalent to solving the halting problem. Is it unlikely to be caught by other forms of testing? No. The moment you run that code in your test case, you're going to get an exception telling you precisely what is wrong.

因此​​，不值得我们而这些警告。有更好的办法，我们可以花费的预算。

Thus, it is not worth our while to make that warning. There are better ways we could be spending that budget.

这篇关于为什么没有这种明显的无限递归给出一个编译器警告？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！