On Tue, 9 Sept 2025 at 16:35, Michael Matz <m...@suse.de> wrote:
> > However, that prevents the contract check from doing its job (diagnosing
> > the bad case).
>
> But it would also be an invalid transformation of the compiler. So I
> can't quite see the worry. The second check ("*p > 5") is conditional on
> the first one:
>
> if (!p)
> fail()
> if (*p > 5)
> fail2()
>
> The *p access would only be unconditional if fail() can fall-through.
>
> Two cases:
> (a) the spec of contracts says that later contracts may depend on earlier
> contracts to have succeeded (dependend contracts): the fail() must not
> fall through, that would be an invalid implementation of contracts,
> and the compiler removing the first !p check would be buggy
> (b) the spec of contracts say that all of them are independend: then
> fail() can fall through and the compiler may indeed remove the !p
> check (if fail() itself doesn't have any interesting side-effects).
> But then the author who wrote those two contracts independendly, where
> in reality one depends on the other, was wrong.
The fail() can fall through when the contracts are evaluated in the
"observe" evaluation mode.
In that case it's not an actual "fail", it will call the contract
violation handler and return from that.
And then the concern is that that call may be completely elided
because what follows is
UB in the form of the pointer dereference.
