I'm not sure if someone has posted this example yet, but here is a fun
example that compiles in both C and C++ with different results:

#include <stdio.h>

int main() {
    while (1)
        ;
}

void unreachable() {
    puts("Hello world!");
}

If you want to try it: https://godbolt.org/z/1d3hzseh4

In C, this code produces an infinite loop while in C++ it does the
following:

[image: image.png]

On Wed, Feb 15, 2023 at 11:31 PM Robert Seacord <rcseacord_at_[hidden]> wrote:

> 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
>