Hans,

I initiated this latest discussion on the WG14 reflector and I've recently
become a bit more active in WG21 (and my boss is JF who wrote this paper).

Here is a recap of some of the history of this issue:

I can't find any forward progress guarantee in the C Standard. The word
"progress" does not appear anywhere in the standard.
Subclause 6.8.5, "Iteration statements" paragraph 5 says:

An iteration statement may be assumed by the implementation to terminate if
its controlling
expression is not a constant expression197), and none of the following
operations are performed in its
body, controlling expression or (in the case of a for statement) its
expression-3198):
— input/output operations
— accessing a volatile object
— synchronization or atomic operations.

197) An omitted controlling expression is replaced by a nonzero constant,
which is a constant expression.
198) This is intended to allow compiler transformations such as removal of
empty loops even when termination cannot be
proven.

N1509 proposes to eliminate 6.8.5p6 in the current WP as the author
believes it to be incompatible with C99. See also N1528, Item 6.30,
Response to N1509.

N1528 covers why the rules were added. N1509 was written to show a
compiler can determine the opposite as well.
In https://open-std.org/jtc1/sc22/wg14/www/docs/n1509.pdf [Walls] contends
that many C90/C99 programs rely on entrance to an unending loop to proceed
no further (within that thread). Those programs are relying on the
semantics of C99 6.8.5p4: "An iteration statement causes a statement called
the loop body to be executed repeatedly until the controlling expression
compares equal to 0."

N1528 breaks existing conforming programs. Adding an exception may solve
the intent of both papers. That approach should be run by Hans. We can
defer a decision and not affect getting a CD out, then respond to an NB
comment. We do want to be compatible with WG21.

ACTION Douglas to work with Larry to come up with the proposed words are:

Change 6.8.5p6 as follows:
An iteration statement whose controlling expression is not a constant
expression (or omitted), that performs no input/output operations, does not
access volatile objects, and performs no synchronization or atomic
operations in its body, controlling expression, or (in the case of a for
statement) its expression, may be assumed by the implementation to
terminate.

Decision: Adopt N1509, as modified above, to the C1X WP. result: 14, 0, 1

On Wed, Feb 15, 2023 at 8:29 PM Hans Boehm via Parallel <
parallel_at_[hidden]> wrote:

> I read the current C wording, and the one proposed here, as saying that
>
> while(true) {
> if (!cond) break;
> ...
> }
>
> may not be assumed to terminate, and is thus very different from
>
> while(cond) {
> ...
> }
>

This is a very confusing shorthand as "..." seems to imply any
syntactically correct statements and thus the first pattern is a subset of
the second pattern.


> I don't remember considering that before. This seems to be completely
> at odds with Olivier's goals. I also don't think this is a good idea, for
> purely loop optimization and understandability reasons. OTOH, some people
> on the WG14 list seem to think it is intentional and desired.
>

Unlike what I said to JF at the meeting, it no longer sounds easy to me to
> remove this C vs. C++ divergence. There seem to be some substantive issues
> here.
>

There is a strong desire in C to remain compatible with C++ and it's less
clear what the C requirement is. There is a requirement that "while (1);"
cannot be assumed to terminate as it is ubiquitous in environments where
you don't have the luxury of calling exit() or yielding to the scheduler.
I certainly wouldn't give up on compatibility at this point, and there is
still a small window to change the C23 language as we are going to a second
CD.

Thanks,
rCs