On Wed, May 24, 2023 at 10:27 AM Hans Boehm <
boehm@acm.org> 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.
If an "operation" is defined in a compound indefinite sense, where a single operation has a start point and an end point, and can consist of multiple smaller "suboperations", where those suboperations are operations, too - like a tree - then the (overall) operation of a thread can be described in the singular. As too could the overall operation of the program.
In that framing, it could be said that if a thread does not eventually do X, then the operation of that thread is an undefined operation.
In posing the concrete interpretation against such a case, the start of the undefined operation is the start of the thread - hence it would render the observable behavior of the entire thread undefined.
It is unclear if such a framing and result preserves the utility of the concrete interpretation N3128 seeks.