Moving the kernel to modern C [LWN.net]

Moving the kernel to modern C

Posted Mar 1, 2022 16:27 UTC (Tue) by ianmcc (guest, #88379)
In reply to: Moving the kernel to modern C by nybble41
Parent article: Moving the kernel to modern C

In C++ the declaration and the body of the loop are the same scope. In C, initializer in the for loop establishes its own scope, so there are actually two scopes created with a C for loop. This was unintended behavior in C, and a defect report was raised about it, but it seems it wasn't seen as important enough. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2257.htm...

After all, who would write such code anyway? Its a strange thing to take issue with.

to post comments

Moving the kernel to modern C

Posted Mar 1, 2022 21:58 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (1 responses)

> In C++ the declaration and the body of the loop are the same scope.

for (init-statement condition[opt] ; expression) statement

The body of the for loop is just *statement*. If the declaration were in that scope it wouldn't survive from one iteration of the loop to the next or be visible in *condition* or *expression*. Declarations in *init-statement* are scoped over the entire for loop, not just the body.

Normally a compound statement within *statement* would introduce its own separate block scope *below* the level of *statement*, but in C++ the lines are blurred between the body of the for loop and the *inside* of the compound statement. In other words, I would expect this to be a redeclaration error, because `char i` and `int i` are declared in the same scope (note that all the examples in the standard are of this form):

for (int i = 0; i < N; ++i)
    char i = 7;

but not this, because `char i` is declared in the new *nested* scope created by the compound statement and not directly in the body of the for loop:

for (int i = 0; i < N; ++i) {
    char i = 7;
}

Contrast this with the following code which the standard (C++20 draft) claims is "equivalent" to the second example "except that names declared in the init-statement are in the same declarative region as those declared in the condition, and except that a continue in statement (not enclosed in another iteration statement) will execute expression before re-evaluating condition":

{
    int i = 0;  /* init-statement */
    while (i < N  /* condition */) {
        { char i = 7; }  // statement
        ++i;
    }
}

In the "equivalent" while loop version there is clearly no redeclaration error—the `char i` declaration is within not just one but two levels of compound statements under the while loop and the scope where `int i` was declared.

> After all, who would write such code anyway? Its a strange thing to take issue with.

Whether you would write that by hand or not, it's an unnecessary (and IMHO completely pointless) complication which moreover breaks compatibility with C. Redeclaration conflicts could appear as a result of macro expansion or other code generation, not just in hand-written code.

Moving the kernel to modern C

Posted Mar 2, 2022 8:56 UTC (Wed) by ianmcc (guest, #88379) [Link]

You've got the history the wrong way around. The behaviour of C++ here hasn't changed since it was first standardized in 1998. At that time, C didn't allow a declaration in a for statement. C99 borrowed the wording from the C++ Annotated Reference Manual, without realizing that the wording had been updated during the C++ standardization process. So C introduced an incompatibility with C++, not the other way around. The C standards committee documents are very clear that this was accidental, not intentional.

The bottom line is that C++ will flag an error in some instances of very dubious code that is most likely a bug anyway (i.e. declaring a variable that shadows the loop control variable) where C99 would allow it. None of the standards committee see it as something worth the bother of fixing. If you really did intend to introduce a shadow declaration, the simple fix is to enclose it in another compound statement.