> On 9 Sep 2025, at 17:46, Ville Voutilainen <ville.voutilai...@gmail.com>
> wrote:
>
> On Tue, 9 Sept 2025 at 19:20, Michael Matz <m...@suse.de> wrote:
>
>> I see. Logging would be a side-effect that has to be retained. There is
>> no correct compiler that could validly elide such call to fail(). Again,
>> the argument is simple: the very act of logging (as any interaction with
>> the outside world) always has the potential to either stop indefinitely or
>> exit the program, thereby avoiding the UB. Such side-effect must be
>> carried out before the UB.
>
> It remains non-obvious whether the C++ standard says that.
>
> With observable_checkpoint(), it becomes much clearer what the standard says,
> and what the guarantees are supposed to be for programs that 'invoke' it
> before
> running into UB.
>
> Yes, the adopted revision of P1494 says a part of that "interaction
> with the outside world",
> but is limited to adding the establishment of an observable checkpoint
> to the functions the
> standard specifies, and it can't really talk about i/o in general
> establishing such a checkpoint, I think,
> because it then becomes a question of what i/o is and how that is
> specified, sigh.
Remembering that here we are not concerned with correct programs
(for which contracts should be NOPs) but for cases where someone
has made a mistake...
---
A way of describing the objective can be:
contracts put a series of independent guard rails around a function
(that *should* ensure that the function is called within its natural-
language contract).
The objective here is that we do not want those guard rails degraded
by some failure in the function body, or even (if possible) by some
failure to express the checks correctly.
If we are not able to do this, then the guard rails might become less
useful - or worse give a false sense of security (to someone who does
not expect that checks might be elided).
One mechanism for improving the utility is to separate checks and to
separate the checks from the function body.
That is my “en_GB” understanding of the intent of the facility - but I
would still recommend reading the paper (it is not long) and then if
there are things not clear or disputed - we can ask the author to
clarify - rather than have a layer of indirection.
thanks
Iain
