Right. ("for (;;);" in the original program does not.)The idea of all this is given in a footnote in the C standards - "This is intended to allow compiler transformations such as removal of empty loops even when termination cannot be proven."
Note that the C++ special rule applies only when the condition is
equivalent to a constant `true` and the body of the loop is empty.
An implementation can "assume" that any other loop will eventually
finish.
The rule in C is (6.8.6.1p4):
An iteration statement may be assumed by the implementation
to terminate if its controlling expression is not a constant
expression, and none of the following operations are performed
in its body, controlling expression or (in the case of a for
statement) its expression-3
— input/output operations
— accessing a volatile object
— synchronization or atomic operations.
`for (;;)` is treated as having a constant controlling expression.
This covers more cases than the C++ rule.
I dislike it for most of the same reasonss. It should be phrased
in terms of the permitted behavior of a program, not what an
implementation is allowed to "assume".
In addition to that, I dislike the whole idea. I think it's
intended to enable optimizations, but it means that for this
contrived program:
#include <stdio.h>
int main(void) {
bool keep_going = true;
while (keep_going) {
keep_going = true;
}
puts("never reached");
}
the implementation is allowed to "assume" that the loop eventually
terminates. It's not clear what permissions the implementation is being
given if the assumption is violated. I think the program could legally
print "never reached", but if violating the assumption implies undefined
behavior it could do anything.
A programmer could easily write a program similar to the above
and think that the meaning is perfectly clear, have it behave very
differently because of one obscure subclause in the standard.
The loop might originally have contained source code, but become empty through pre-processing, or from other compiler transformations (such as the compiler seeing that the "keep_going" variable is not volatile and its value is never used, so assignments to it can be elided, or moving other things outside the loop body).
A programmer /could/ write the "keep_going" loop you gave, and mistakenly believe it to be infinite. But is it likely? In my experience, infinite loops are generally very clearly written - either as "for (;;)" loops or "while (true)" loops - or they are the result of bugs in the code that accidentally run forever. If the loop is accidentally infinite, the programmer will already be expecting it to run the code after the loop.
Equally, I don't think it is likely that compilers will often be able to use this rule to improve code generation - it would only help in a situation where the loop's controlling expression is too complicated for the compiler to be sure that it will terminate, but where the loop body ends up effectively empty. I doubt if that turns up often in real code either.
So while I agree that this kind of thing can lead to curiosities and behaviour that seems counter-intuitive, and is popular with the "modern compilers are evil" crowd, I really do not see it as an issue in practice. There are many other mistakes programmers can make, or UB that they hit accidentally - this is a drop in the ocean IMHO.
Les messages affichés proviennent d'usenet.