On 10/06/2026 23:47, Keith Thompson wrote:I think we should not make any assumptions about the "creativity" of a[...][...]
>
#include <stdio.h>
int main(void) {
bool keep_going = true;
while (keep_going) {
keep_going = true;
}
puts("never reached");
}
>
[...]
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?
programmer ("C" or else). - Semantics should be well defined, and then
clear to the programmer.
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.Languages shall be sensibly and clearly defined. For bad designs (or
[...]
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.
bad standards) the language or standard should be blamed, and not the
critics badly and inappropriately despised as ''"modern compilers are
evil" crowd''. - Programmers are at the final end of the "food chain".
And there's a lot of horrible pits in the C-language where programmers
"made the mistake" to fall in; don't blame them, neither the ones who
silently suffer nor the ones who shout out.
Janis
Les messages affichés proviennent d'usenet.