Scope rules of `for` loop different in C++ than in C? [duplicate]

Question

I noticed that the scope rules of the for loop are different for C and C++.
For example, the code below is legal in the C compiler, but not legal in the C++ compiler.

for (int i = 0; i < 10; ++i) {
    int i = 5;
}

The above code is valid in C, but gives a redefinition error in C++.
My guess is that the C compiler treats the loop as if there is another scope inside the loop like below.

for (int i = 0; i < 10; ++i) {
    {
        int i = 5;
    }
}

Why does the C compiler allow a second variable with the same name to be defined in the scope of the loop? Is there any particular reason or advantage for doing this?

Answer 1

As far as standards go, for loop scopes are indeed defined differently in C and in C++. In C they are defined as follows:

6.8.5.3 The for statement

The statement

for ( clause-1 ; expression-2 ; expression-3 ) statement

behaves as follows: ...

with no specific reference given to limitations on variable declarations inside the statement. The top-level description of loops ("iteration statements" in the standard) specifies:

An iteration statement is a block whose scope is a strict subset of the scope of its enclosing block. The loop body is also a block whose scope is a strict subset of the scope of the iteration statement.

as you've hinted in your question, code like:

for (int i = 0; i < 10; ++i)
    int i = 5;

where a new block is not declared (notice the missing { } surrounding the redeclaration) - is not valid code.

---

Whereas in C++, there is a specific reference to redeclaration of loop variables:

8.6 Iteration statements specify looping ... If a name introduced in an init-statement or for-range-declaration is redeclared in the outermost block of the substatement, the program is ill-formed.

---

As it relates to rationale - likely C++ just added the restriction as an improvement to language semantics, indeed redeclaring a variable this way is usually a bug.

Arguably, this restriction is appropriate in C as well - but adding this restriction to the C standard would break backwards compatibility with existing code and is unlikely to happen.