On 2026-06-11 08:56, David Brown wrote:I think the semantics of this "loops can be assumed to terminate" are clearly defined in the standard. I agree that the details might not be known to all C programmers, but I think they are only relevant in a very small number of cases.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.
I agree that standards should be clear, and standards documents should be held accountable if they are not. There's no doubt that the C standards are not perfect (Keith's "42 is not an expression" is an example of that).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.
But it is less obvious that the language should be blamed for bad design. As a wise man here said, "C is what it is". The reasons for design decisions might be lost to history, inappropriate for a modern language, or forced for compatibility reasons - but the language stands with the rules it has. I don't know of anyone who uses a mainstream programming language for serious work and does not think at least some of its design decisions are bad - "bad" is highly subjective, depending on both the programmer and the type of work they do. Just like for any programming language, if you are programming in C, then you need to be aware of the pitfalls of C or steer well clear of where pitfalls might be.
Ultimately, programming languages are subject to the equivalent of market forces - the choice of language to use for a particular task is a matter of weighing up what you think are the good and bad points for available alternatives. As the incumbent in many situations, C of course has an unfair advantage - but with enough incentive, people move to other languages with their own benefits, disadvantages, and "bad" design decisions. This is a slow process, but it is the only way forward.
As for my '"modern compilers are evil" crowd' comment, there are people (not anyone involved in this discussion) who really do fall into that camp. I've seen people who are experienced and respected developers make all sorts of accusations to compiler developers, claiming they are only interested in high scores on synthetic benchmarks and directly insulting their motivations and integrity, blaming them for "breaking" their code that relied on the effects of some kinds of UB. It is always frustrating when you have code that works fine with one compiler version, but using another compiler results in failure due to UB in your code - especially if writing correct code gives inefficient results with the first compiler. And it's fine to say you'd be happier if a particular thing that is UB in C were not UB - but it is unreasonable to blame compiler developers for implementing the language as it is defined.
I am not in any way saying that critics of aspects of C (the language, the standards, or compiler implementations) should be dismissed or despised - merely that the example of loop elimination leading to UB and unexpected results is regularly used as "evidence" by those that hold extreme positions about C, despite it being very unrealistic for the issue to cause problems in real coding practice.
It is always best if compilers are able to warn you about problems in your code - such as UB - and avoid surprising results. But I don't think it is practical to expect them to catch everything, and too many warnings will flood you with false positives. (gcc used to have a warning for when code was elided - as the compiler got stronger and gained more optimisations, the warning was dropped because eliding code happened far too often to warn about.)
Les messages affichés proviennent d'usenet.