Martin,

on Sat, 27 May 2023 15:52:57 +0200 you (Martin Uecker
<ma.uecker_at_[hidden]>) wrote:

> 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:
> [...]
> > >
> > > 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.

For me it has the same status as discussing life after death.

> But it is also not nothingness. It is actual machine behavior, just
> arbitrary.

Exactly, it is machine behavior and not program behavior, outside
the scope of the C standard by definition. What is happening after a
fault is typically subject to OS definitions, not PL.

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

Yes, and that is exactly where I cannot follow, and where I think that
it is an abuse of terminology.

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

I wouldn't be so sure and would delay making up my opinion to the day
that we have come up with a concrete catalogue of faults and of a
consciously chosen set of extension possibilities for implementations.

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