On Tue, May 23, 2023 at 12:19 AM Jens Maurer <jens.maurer_at_[hidden]> wrote:

>
>
> On 23/05/2023 03.34, Andrew Tomazos via Liaison wrote:
> ...
> > Is it correct to say that a statement of the form "The implementation
> may assume X", implies that if X is false, the program has undefined
> behavior?
> >
> > If so, the condition X may not contain any reference to an undefined
> operation, such as [intro.progress]/1 does not:
> >
> > "The implementation may assume that any thread will eventually [snip]"
> >
> > Thus it is not rendered undefined behavior via [intro.abstract]/4,
>
> [intro.abstract] p4 is the root of the "undefined behavior" specification
> in C++.
> I agree the phrasing "operation" is not stellar with respect to stuff such
> as
> non-terminating loops or data races (improvement suggestions welcome), but
> the
> intent is that it applies to all kinds of undefined behavior that are
> mentioned
> in the rest of the standard.
>
I wished we had explicitly called it "undefined behavior". I don't think
there is
another interpretation of that statement that makes sense, and it was
certainly
my intent that it be undefined behavior, but the wording is confusing.

Hans

>
> Jens
>