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.


> 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.

Thanks
Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::