Am Samstag, dem 27.05.2023 um 14:04 +0200 schrieb Jₑₙₛ Gustedt:
> Martin,
>
> on Sat, 27 May 2023 13:16:27 +0200 you (Martin Uecker
> <ma.uecker_at_[hidden]>) wrote:
>
> > 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.
>
> I think the primary problem is already on a (natural) language
> level. In plain English there seems to be a clear distinction between
>
> The behavior is not defined (or undefined).
>
> and
>
> This has undefined behavior.
>
> and
>
> This invokes undefined behavior.
>
> This is sematically on the same level as talking of nothingness.

I do not understand the distinction. To me, behavior
which is not defined is the same as undefined behavior.

But it is also not nothingness. It is actual machine
behavior, just arbitrary. The standard uses the term
in this way, e.g. "An example of undefined behavior
is the behavior on dereferencing a null pointer." or
"undefined behavior (3.4.3) that does not perform an
out-of-bounds store." Both imply actual behavior
and not an abstract state where all semantics of a
program disappear.

>
> > Nevertheless, I like the idea of introducing the term
> > "faul" as below:
>
> great!
>
> > 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.
>
> yes
>
> (not all of the terms would be new, I'd suspect)
>
> I think that this is overdue for C. Instead of putting all problems in
> one bag and putting a "☢" sign on it to scare the children, we should
> have a constructive approach and address the real and concrete
> problems that arise.

I agree we should do this, but I do not think it is sufficient.
For implicit UB there is nothing to rename, so to address this,
the whole concept of abstract UB must die in my opinion (or
must be limited to very specific situation, but not be the
default).

Martin