Hello, On Tue, 9 Sep 2025, Ville Voutilainen wrote:
> > On Tue, Sep 09, 2025 at 06:08:12PM +0300, Ville Voutilainen wrote: > > > 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. > > > > IMHO a correct compiler can't do that. > > Because the contract violation handler could have validly exit (0) > > or for (;;) ; etc. in it, so the UB wouldn't encountered in the program and > > so it would be valid. > > The violation handler may be defined in the same translation unit, and > its definition may be completely visible > to the middle-end. So the fear is that the violation handler for the first contract is (to the compiler) visibly no-op (side-effect-free), right? But then I have to ask what the author of the contract intended with the in(p) constraint when nothing is done when it fails? It would then be equivalent to just have written a single contract in(*p > 5). What would prevent the segfault in that case? Ciao, Michael.
