Why doesn't this obvious infinite recursion give a compiler warning? [closed]

Answer 1

No compiler of any programming language has any sort of idea about the semantics of the code it compiles. This is valid code, though stupid, so it will be compiled.

Answer 2

How is the compiler or interpreter suppose to know what the function is doing? The scope of the compiler and interpreter is to compile or interpret the syntactical code-- not interpret the semantics of your code.

Even if a compiler did check for this, where do you draw the line? What if you had a recursive function that calculated factorial forever?

Answer 3

As you have mentioned Compiler just checks syntatical errors. the recursive function isperfectly valid w/o any error.

During Runtime,

when stack is overflown it throws an error because of stack overflow *not because of code*.

Recursive function is perfetly valid, but again in implementation we need to put condition check to return values before stack is filled.

Answer 4

I doubt the compiler can detect a run-time phenomena (stack overflow) at compile time. There is many valid cases to call a function inside itself, recursion. But how can the compiler know the good from the bad cases of recursion?

Unless it has some added AI to it, I don't think a compiler could detect the differences between good and bad recursion, that's the job of a programmer.

Answer 5

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:

• 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.

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.

Answer 6

Because compiler will not check for these kind of stuff.

If you install a code analyzer like Resharper in Visual Studio it bring a warning of infinite recursive call or sth like that in case you enabled the code analysis option.