Am Fr., 17. Feb. 2023 um 10:52 Uhr schrieb Aaron Peter Bachmann via
Liaison <liaison_at_[hidden]>:
>
> Hello Robert!
> I understand the while(1)-loop can be assumed to terminate.
> But who calls unreachable()? It is not in the body of main().

That was my initial thought as well, but after the discussion
proceeded I understood that the original shown code example did not
content a typo.

It seems that the compiler sees the puts statement and concludes that
it must finally called, regardless of a missing call.

- Daniel
> I would expect main() to return with 0 for C and an unspecified value
> for C++
> or alternatively remain in the endless loop for both languages.
>
> Regards, Aaron Peter Bachmann
>
> On 2/16/23 05:42, Robert Seacord via Liaison wrote:
> > 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.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
> >
> >
> > _______________________________________________
> > Liaison mailing list
> > Liaison_at_[hidden]
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > Link to this post: http://lists.isocpp.org/liaison/2023/02/1175.php
>
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2023/02/1178.php