> On 8 Sep 2025, at 15:53, Richard Biener <richard.guent...@gmail.com> wrote:
>
>
>
>> 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.
I fear we might be getting de-railed somewhat from the P1494 case - IIUC
contracts is only one use.
I do not suppose that there are many designs for which we all agree with
all the details - for the discussions here, I am just trying to represent what
I believe to be the designer’s intents (so not necessarily my personal POV).
Trying to see how to proceed here; currently P1494 + P3641 are part of the
working draft, and so are expected to be in C++26.
If it is demonstrably the case that the design is not useable - then we should
raise a comment to that effect (soon, because the deadline is close).
Otherwise, I’m looking for guidance on what’s needed to land this.
thanks
Iain
>
> Richard
>>
>> Iain
>>
