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

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

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ₑₙₛ

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