> Am 08.09.2025 um 16:28 schrieb Iain Sandoe <i...@sandoe.co.uk>:
>
>
>
>>> On 8 Sep 2025, at 15:20, Iain Sandoe <i...@sandoe.co.uk> wrote:
>>>
>>>
>>>
>>>> On 8 Sep 2025, at 15:05, Jakub Jelinek <ja...@redhat.com> wrote:
>>>
>>> On Mon, Sep 08, 2025 at 02:54:18PM +0100, Iain Sandoe wrote:
>>>> (for pre-conditions) they lower to a series of statements like
>>>> if (some check fails)
>>>> handle the contract violation
>>>> if (some other check fails)
>>>> handle the contract violation
>>>> …
>>>>
>>>>> The only "example" is for in(p) in (*p > 5) where the contract
>>>>> *p > 5 would "elide" the 'p' one. Whatever "eliding" means here.
>>>>
>>>> So, IIRC, the argument was
>>>>
>>>> *p > 5 would be UB for p == nullptr
>>>>
>>>> therefore an earlier check for p == nulptr can be removed, because
>>>> that case cannot happen in a well-formed program.
>>>>
>>>> However, that prevents the contract check from doing its job (diagnosing
>>>> the bad case).
>>>>
>>>> I cannot say that GCC would make that optimisation - it was, in general,
>>>> quite hard to find cases that time-traveled.
>>>
>>> If handle the contract violation is just __builtin_unreachable () or
>>> it isn't evaluated at all and handled more like [[assume ()]] for the ignore
>>> semantics, then I don't see a problem with that kind of time travel.
>>> If handle the contract violation is a function call which gcc knows nothing
>>> about (including calling ::handle_contract_violation), I don't see how gcc
>>> could optimize that (unless it is buggy), exactly because it needs to count
>>> with the function exiting or looping forever or doing thread synchronization
>>> and other threads observe the state etc.
>>
>> The contract violation handling depends on the chosen contract semantic
>> it can:
>>
>> * terminate (in an implementation-defined way - so could trap or abort
>> equally).
>> * do some diagnostic output or logging and then terminate (etc).
>> * do some diagnostic output or logging and then continue.
>>
>> I completely agree with Richi that, in the given case, continuation means
>> that the program will segv. I guess the question is whether the violation
>> handler logging a cause before that is considered a useful functionality.
>
> I think the big thing with contracts is that they are not there to deal with
> correct programs, they are there to try and help in the case that the program
> is buggy (in a way that cannot be detected at compile-time).
Usually sth like contracts aids in formal program verification. But … too many
C++ papers to read. Still C++ sometimes feels like going the „coming from X,
now also available in C++“, aka chasing for feature completeness as its own
merit.
Richard
>
> Iain
>
