C++ Logo


Advanced search

Re: [wg14/wg21 liaison] UB

From: Jₑₙₛ Gustedt <jens.gustedt_at_[hidden]>
Date: Sat, 27 May 2023 14:04:48 +0200

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


       This has undefined behavior.


      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:


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


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


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

Received on 2023-05-27 12:04:52