Am Freitag, dem 26.05.2023 um 10:25 +0200 schrieb Jₑₙₛ Gustedt via Liaison:
> Hello Joshua,
> I share your sentiment.
>
> My impression is that we in large parts have just a problem with our
> terminology. The term "undefined behavior" is indeed in our
> communities often deviated from its primary sense "there is no
> definition that would describe the behavior". I think it would be good
> if we could just separate this.
>
> For me, the concept that Martin tries to describe as "concrete UB" is
> just not UB but an event that leads to UB. Let's just change
> terminology and call such an event a fault. I would go for something
> like

I am not referring to the event that leads to UB but the
actual behavior that occurs under such a condition.

In the abstract interpretation the UB does not refer to any
concrete behavior at all, it is the idea that the whole program
has no semantics at all. This can be reconciled with the term
"behavior" only by invoking metaphysical concepts (demons,
time-travel, etc.) which extend the meaning in the term
"behavior" in a way that goes beyond its original meaning.

I do not think this extension is a good idea. If it is
rally needed in some situation, but then it should be
restricted specifically to very specific cases and also
have a different name.


Nevertheless, I like the idea of introducing the term
"faul" as below:

>
> *undefined behavior*
>
> behavior for which this document imposes no requirements
>
> Note 1 to entry: Possible undefined behavior ranges from
> ignoring the situation completely with unpredictable results,
> to behaving during translation or program execution in a
> documented manner characteristic of the environment (with or
> without the issuance of a diagnostic message), to terminating
> a translation or execution (with the issuance of a diagnostic
> message).
>
> and
>
> *fault*
>
> an erroneous operation or event after which the behavior of
> the program execution becomes undefined
>
> Note 1 to entry: The occurence of a fault is an event during
> the execution of a program. A conforming program produces all
> visible side effects that happen bevor to such a fault.
>
> Note 2 to entry: J.2 gives an overview over operations in C
> programs that lead to faults.
>
> EXAMPLE An example of a fault is dereferencing a null pointer.
>
> Maybe that catches the difference that Martin wants to make.
>
> Clearly then we would have to update the standard in all places where
> it claims explicit UB and change the language to "fault".

One problem is that not all UB in the standard are faults. Some
are extension points or simple cases where we do not care exactly
how the implementation behaves, but we expect the program to still
work. So one would also need a new term for such things. Also
one would need to go over the whole standard and classify things
into different categories.

Martin

>
> Examples:
>
> 5.1.2.4 p 35 (Multi-threaded execution …) of the C
> standard
>
> The execution of a program
> <del>contains</del><ins>encounters</ins> a data race if it
> <del>contains</del><ins>performs</ins> two conflicting actions in
> different threads, at least one of which is not atomic, and
> neither happens before the other. <del>Any such data race results
> in undefined behavior.</del> <ins>Any such conflicting action is a
> fault.</ins>
>
> Section 6.5.2.3 (Structure and union members) p5
>
> Accessing a member of an atomic structure or union object
> <del>results in undefined behavior</del><ins>is a fault</ins>.
>
> Or in the library section 7.14.1.1 (signal) p7
>
> Use of this function in a multi-threaded program <del>results in
> undefined behavior</del><ins>is a fault</ins>. The implementation
> shall behave as if no library function calls the `signal`
> function.
>
> … and so on.
>
> So that would mean that we'd have some work to do, but Martin and I
> have some experience with such an wide-range update when clearing up
> the language of what previously was "indeterminate value". So I think
> that this would be doable.
>
> Thanks
> Jₑₙₛ
>
> _______________________________________________
> 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/05/1206.php