David Brown <david.brown@hesbynett.no> writes:I agree on that last point. I doubt if any code would suffer if the paragraph were removed entirely from the standard. And while I also don't think much real-world code is at risk of problems from its inclusion in the standard, as long as there is some risk of problems with existing correct code, or some risk of confusion or misunderstanding on the part of programmers reading the standard, then it would be better if that paragraph had not been added to the standard at all.On 11/06/2026 17:34, Janis Papanagnou wrote:I disagree that the semantics are clearly defined. N3220 6.8.6.1p4On 2026-06-11 08:56, David Brown wrote:>On 10/06/2026 23:47, Keith Thompson wrote:>[...]>
>
#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?
I think we should not make any assumptions about the "creativity" of
a programmer ("C" or else). - Semantics should be well defined, and
then clear to the programmer.
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.
is specified in terms of what an implementation may "assume", not in
terms of the semantics of the program. One can conclude that this
means that the program has undefined behavior if the assumption is
violated, but that's not directly stated. I don't know how many C
programmers know the standard well enough to reach that conclusion.
I'm not even 100% sure it's accurate.
The permission was added in C11 with little fanfare. It's not
mentioned in the list of major changes in the C11 Foreword.
The cases where it applies may be rarer than I had assumed, but
it at least has the potential to break existing code that was well
defined in C99.
The rationale is to provide more opportunities for optimization,
but it's not at all clear (at least to me) that it's particularly
successful. If cases where it can cause problems are rare, then
presumably cases where it's actually useful are rare. (That may
be an oversimplification.)
Les messages affichés proviennent d'usenet.