In article <110fgbi$1qf9f$1@kst.eternal-september.org>,I think perhaps there is both undefined and unspecified aspects here.
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:cross@spitfire.i.gajendra.net (Dan Cross) writes:The two choices are that the implementation may assume the loopIn article <110cre9$13aa9$1@kst.eternal-september.org>,>
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:cross@spitfire.i.gajendra.net (Dan Cross) writes:>
[...]I see you did not read the other messages in the (sub)thread,>
but ok, here it is again, in C:
>
```
term% cat what.c
#include <stdio.h>
int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
void hello(void) { printf("Hello, World!\n"); }
term% clang --version | sed 1q
clang version 22.1.6
term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
what.c:2:58: warning: for loop has empty body [-Wempty-body]
2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
| ^
what.c:2:58: note: put the semicolon on a separate line to silence this warning
1 warning generated.
term% ./what
Hello, World!
term%
```
I see the same behavior.
>
The following largely repeats what I've written previously in
this thread.
>
Apparently the authors of clang decided that this statement in N3220
6.8.6.p4:
>
An iteration statement may be assumed by the implementation to
terminate if its controlling expression is not a constant
expression, ...
>
means that a program that violates that assumption has undefined
behavior. I intensely dislike both the rule and the way it's stated,
but I agree that the conclusion that the behavior is undefined is
a reasonable one.
I think the behavior is technical "unspecified" in the sense of
the C standard, but yes, this is the important bit. The
controlling expresion is not constant, and the loop doesn't meet
any of the other criteria set forth in sec 6.8.6 para 4 for,
therefore, the translator may assume it terminates (it is
unspecified whether or not it does; either behavior is correct.
GCC, for example, appears not to make the same assumption).
Why do you think the behavior is unspecified rather that undefined?
>
Unspecified behavior is defined as: "behavior, that results from
the use of an unspecified value, or other behavior upon which
this document provides two or more possibilities and imposes
no further requirements on which is chosen in any instance".
(Implementation-defined behavior differs from unspecified behavior
in that the implementation must document how the choice is made.)
>
What are the "two more more possibilities" in this case?
terminates, or it may not, but it doesn't say which. I don't
think that the language permits it to be UB. But I could be
wrong. It's a bit of a distinction without a difference as far
as the outcome is concerned.
- Dan C.
The implementation may assume the loop terminates - that means, to me, that there are no requirements for what happens if the loop does not terminate. Not terminating would be UB.
However, I don't support clang's reasoning after that in this case. As I see it, a compiler can reason that the loop terminates and then executes "return 0;" because the non-terminating situation is UB and cannot occur. Thus it can skip the loop and go straight to "return 0;". Alternatively, it can reason that the non-terminating situation is UB and we don't care what happens if it does not terminate - so "return 0;" would be fine in that case too, simplifying the generated code.
But it seems that clang is reasoning that it can assume the loop terminates, and it can prove that the loop does not terminate, and this contradiction means that anything is allowed (including skipping all code generation). The code has two conflicting semantics - it is an infinite loop, and it is a terminating loop. I think the standards say that the compiler /may/ consider the terminating loop interpretation as correct, thus giving just "return 0;", or it may choose not to consider that it terminates, and generate an infinite loop. Clang appears to think that it can pick both options at once, which would give contradictory behaviour, and therefore jump straight to UB.
I would say that the best behaviour for a compiler here would be to give a warning, then it should pick one or the other defined behaviours. (gcc picks the infinite loop, but does not give any warning.) I cannot say for sure that clang's behaviour is incorrect - but it is certainly very unhelpful and poor quality of implementation.
(I also think that it makes sense for compilers to use the "ud2" or similar "undefined behaviour" trap instructions in cases where they know an execution path is definitely UB and doing so does not affect the efficiency of non-UB paths.)
Les messages affichés proviennent d'usenet.