Date: Thu, 23 Oct 2025 15:04:59 -0700
> On Oct 23, 2025, at 2:48 PM, Herb Sutter via Ext <ext_at_[hidden]> wrote:
>
> To everyone who has the “contracts can inject new UB in observe mode” concern: This is a fine concern. I encourage you to keep raising it and we will hear it again in Kona. Summarizing the “new UB” concern for everyone, it’s that in cases like the following, the second line might introduce “new” UB if the body of the function doesn’t otherwise dereference p:
>
> contract_assert (p != nullptr);
> contract_assert (p->foo());
>
Is the issue that in observe mode in this case that these contract assertions turn into something like (pseudo code)
if (p != nullptr) report();
if (!p->foo()) report();
And the compiler is permitted to assume that `p->foo()` means that `p` is nonnull and back propagate that assumption forward or backwards through time?
I had thought that the observable checkpoints were intended to act as a fence that prevented such optimization?
—Oliver
>
> To everyone who has the “contracts can inject new UB in observe mode” concern: This is a fine concern. I encourage you to keep raising it and we will hear it again in Kona. Summarizing the “new UB” concern for everyone, it’s that in cases like the following, the second line might introduce “new” UB if the body of the function doesn’t otherwise dereference p:
>
> contract_assert (p != nullptr);
> contract_assert (p->foo());
>
Is the issue that in observe mode in this case that these contract assertions turn into something like (pseudo code)
if (p != nullptr) report();
if (!p->foo()) report();
And the compiler is permitted to assume that `p->foo()` means that `p` is nonnull and back propagate that assumption forward or backwards through time?
I had thought that the observable checkpoints were intended to act as a fence that prevented such optimization?
—Oliver
Received on 2025-10-23 22:05:13
