Pre-C23 check in for declaration is incorrect

[Halalaluyafail3]

Clang incorrectly rejects the following statement pre-C23 with -pedantic-errors:

for(_Static_assert(1,"");0;);

This is valid, yet Clang rejects it anyways. Additionally, Clang incorrectly allows the following:

for (enum fred { jim, sheila = 10 } i = jim; i < sheila; i++);

This is invalid and is mentioned specifically in DR277.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (Halalaluyafail3)

Clang incorrectly rejects the following statement pre-C23 with -pedantic-errors: ```c for(_Static_assert(1,"");0;); ``` This is valid, yet Clang rejects it anyways. Additionally, Clang incorrectly allows the following: ```c for (enum fred { jim, sheila = 10 } i = jim; i < sheila; i++); ``` This is invalid and is mentioned specifically in [DR277](https://www.open-std.org/jtc1/sc22/wg14/issues/c99/issue0277.html).

[frederick-vs-ja]

Clang incorrectly rejects the following statement pre-C23 with -pedantic-errors:

for(_Static_assert(1,"");0;);

This part was previously reported in #56471.

As I said before:

it seems not very clear whether it is allowed to declare no identifier (e.g. the declaration is a static assertion)

---

Additionally, Clang incorrectly allows the following:

for (enum fred { jim, sheila = 10 } i = jim; i < sheila; i++);

This is invalid and is mentioned specifically in DR277.

Agree. Perhaps we should reject this before C23 like GCC.

[llvmbot]

@llvm/issue-subscribers-c

Author: None (Halalaluyafail3)

Clang incorrectly rejects the following statement pre-C23 with -pedantic-errors: ```c for(_Static_assert(1,"");0;); ``` This is valid, yet Clang rejects it anyways. Additionally, Clang incorrectly allows the following: ```c for (enum fred { jim, sheila = 10 } i = jim; i < sheila; i++); ``` This is invalid and is mentioned specifically in [DR277](https://www.open-std.org/jtc1/sc22/wg14/issues/c99/issue0277.html).

[Halalaluyafail3]

Clang incorrectly rejects the following statement pre-C23 with -pedantic-errors:
for(_Static_assert(1,"");0;);

This part was previously reported in #56471.

As I said before:

it seems not very clear whether it is allowed to declare no identifier (e.g. the declaration is a static assertion)

I don't see how this is unclear:

The declaration part of a for statement shall only declare identifiers for objects having storage class
auto or register.

Section 6.8.5 "Iteration statements" Paragraph 2 ISO/IEC 9899:2018

It says that it shall only declare identifiers for objects having storage class auto or register, not that it shall declare at least one.

[frederick-vs-ja]

It says that it shall only declare identifiers for objects having storage class auto or register, not that it shall declare at least one.

So did you mean that a requirement of form "one shall only do something meeting some conditions" can imply that "one is allowed not to do this kind of things", and thus is not strictly stricter than "one shall do something"? It's not clear to me whether such reading works.

If your reading holds, IIUC it would be equivalent to (and possibly should be rephrased to):

Each identifier declared in the declaration part of a for statement shall refer to [...]

, which clearly avoids imposing requirement when no identifier is declared.

---

Anyway, it seems that the constraints for for statements weren't synchronized with the addition of declarations declaring no identifier, and the chance for clarification in the standard wording seems lost now, which is quite unfortunate.

[Halalaluyafail3]

It says that it shall only declare identifiers for objects having storage class auto or register, not that it shall declare at least one.

So did you mean that a requirement of form "one shall only do something meeting some conditions" can imply that "one is allowed not to do this kind of things", and thus is not strictly stricter than "one shall do something"? It's not clear to me whether such reading works.

Consider the following paragraph:

A type specifier of the form

enum identifier

without an enumerator list shall only appear after the type it specifies is complete.

Section 6.7.2.3 "Tags" Paragraph 3 ISO/IEC 9899:2018

If the words "shall only" are stricter than just "shall", then presumably this program is invalid since it violates the constraint:

enum E{e};
int main(void){}

Here is another example:

A return statement with an expression shall not appear in a function whose return type is void. A
return statement without an expression shall only appear in a function whose return type is void.

Section 6.8.6.4 "The return statement" Paragraph 1 ISO/IEC 9899:2018

If the words "shall only" are stricter than just "shall", then presumably this program is invalid since it violates the constraint:

void foo(void){}
int main(void){}

Clearly it's not intended for these programs to be invalid, so it wouldn't make sense for "shall only X" to require X to be done just like "shall X".

[frederick-vs-ja]

These example indicate that "X shall only Y" allows X to be absent. But IIUC "X shall Y" also allows Y to be absent.

The case for the old specification for for statements is a bit different - the declaration part of a for statement can be absent, in which case the related rule just doesn't apply. However, I think the requirement should be conclude as "X shall only Y under restriction Z". It's weird to me to consider that such requirement allows that "X is present but doesn't Y".