Date: Wed, 24 May 2023 12:13:37 +1000
On Wed, May 24, 2023 at 10:27 AM Hans Boehm <boehm_at_[hidden]> wrote:
>
>
> 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.
>
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.
>
>
> 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.
>
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.
Received on 2023-05-24 02:13:51