The "separate entry point" that skips assertions does not introduce runtime
overhead (just a bit of dead code in binary size) but we could easily make
strip deal with that.

On Mon, Oct 20, 2025 at 12:39 PM Timur Doumler <cpp_at_[hidden]> wrote:

> Yes, it's a valid strategy and P3846 talks about that too (see Concern 2)
> — but that introduces overhead even on ignored assertions, and you are
> relying on LTO to remove that overhead, but there is no guarantee that will
> always work. For many people, guaranteed zero overhead on ignored
> assertions — which C assert and similar assertion macros provide — is an
> important requirement. In a nutshell, you won't liberally and widely add
> assertions to your code if you can't be sure there is a way to have them do
> nothing at all.
>
> Cheers,
> Timur
>
> On 20 Oct 2025, at 13:33, Gašper Ažman via SG15 <sg15_at_[hidden]>
> wrote:
>
> You can definitely do it with conventional linkers. You guard the check
> with a link-time constant semantic at code emission; you let the linker
> fill those in. The link-time constant is a global that the linker
> deduplicates.
>
> You can also introduce additional labels that skip the checks in the
> preconditions, and let the linker resolve the calls to those. Normal
> linkers do this. It works for weak symbols too.
>
> On Mon, Oct 20, 2025 at 11:57 AM John Spicer <jhspicer_at_[hidden]> wrote:
>
>> That assumes facilities that linkers might not have, and even if they
>> have them, it may require expert use to select the version of the function
>> you want.
>>
>> This also potentially requires you to *know* which functions you and your
>> libraries use.
>>
>> On most systems with conventional linkers you do not have the capability
>> you describe.
>>
>> John.
>>
>> On Oct 20, 2025, at 6:52 AM, Gašper Ažman via SG21 <sg21_at_[hidden]>
>> wrote:
>>
>> John,
>>
>> it shouldn't be "assigned randomly" - it's at best a final link-time
>> property (as specified). The final link (+LTO) can do it.
>>
>> On Mon, Oct 20, 2025 at 11:50 AM John Spicer <jhspicer_at_[hidden]> wrote:
>>
>>> The problem is that for function templates, member functions of class
>>> templates, and inline functions, the semantic is essentially assigned
>>> randomly if it is used in multiple TUs that are compiled with different
>>> semantics.
>>>
>>> In most complex environments you are dealing with things like libraries
>>> that are provided by others, so you may not have control over how it is
>>> built.
>>>
>>> You can also have two libraries that use a third library, but if those
>>> two libraries are a different semantic any user of the third library has no
>>> idea what semantic they’ll get even if their code also uses the third
>>> library and is built with a particular semantic.
>>>
>>> John.
>>>
>>> On Oct 17, 2025, at 11:45 AM, Gašper Ažman via SG21 <
>>> sg21_at_[hidden]> wrote:
>>>
>>> +1 to what Tom said.
>>>
>>> One part of this discussion is speaking as if semantics are assigned
>>> randomly or arbitrarily, where they are assigned by the person who ships
>>> the product - it has been pointed out time and time again that the actor
>>> deploying the application is the final arbiter of what "safe" means for a
>>> given contract check, because it's actually a function of "safe(context) ->
>>> bloom" (where "bloom" is a type with exactly two values of "no" and
>>> "perhaps").
>>>
>>> The stakeholder with the best context is the deployer of the
>>> application; the farther away you go from that stakeholder, the less
>>> context they have. Deferring the choice of semantic to as late as possible
>>> gives a better outcome.
>>>
>>> On Fri, Oct 17, 2025 at 4:33 PM Tom Honermann via SG21 <
>>> sg21_at_[hidden]> wrote:
>>>
>>>>
>>>> On Oct 17, 2025, at 10:23 AM, Harald Achitz via SG21 <
>>>> sg21_at_[hidden]> wrote:
>>>>
>>>> 
>>>> On 2025-10-17 16:00, René Ferdinand Rivera Morell wrote:
>>>>
>>>> On Fri, Oct 17, 2025 at 8:53 AM Harald Achitz via SG15 <
>>>> sg15_at_[hidden]> wrote:
>>>>
>>>>> Today's
>>>>>
>>>>> void fun(Foo* ptr) {
>>>>> my_supper_assert_macro (ptr!=nullpter);
>>>>> my_supper_assert_macro(ptr->hasData());
>>>>> }
>>>>>
>>>>> should not have any problems, ever
>>>>>
>>>>
>>>> AFAIU, if my_supper_assert_macro implements something equivalent to
>>>> observe, that is still UB at present. Or is it EB now?
>>>>
>>>> --
>>>> -- René Ferdinand Rivera Morell
>>>> -- Don't Assume Anything -- No Supongas Nada
>>>> -- Robot Dreams - http://robot-dreams.net
>>>>
>>>>
>>>> On devices that keep you alive, one example where I have seen such
>>>> super asserts in action, contracts are contracts They do not exist only
>>>> sometimes.
>>>>
>>>> Correct, (plain language) contracts are omnipresent. The contract
>>>> checking statements above violate the function contract and are thus
>>>> defective. Static analysis can diagnose such cases. For example, I would
>>>> expect a contracts enabled version of Coverity to report a FORWARD_NULL
>>>> issue for the above code.
>>>>
>>>>
>>>> I am not even sure if contracts as specified would pass regulatory
>>>> requirements, I think not.
>>>>
>>>> I’m not an expert on the subject by any means, but I would expect
>>>> regulatory requirements to consider the manner in which the software is
>>>> built; just as they consider the content of the source code and require
>>>> other supply chain guards. A requirement that deployed software not contain
>>>> portions for which the observe semantic is selected seems reasonable and
>>>> prudent.
>>>>
>>>> Tom.
>>>>
>>>> /Harald
>>>>
>>>> _______________________________________________
>>>> SG21 mailing list
>>>> SG21_at_[hidden]
>>>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
>>>> Link to this post: http://lists.isocpp.org/sg21/2025/10/11351.php
>>>>
>>> _______________________________________________
>>> SG21 mailing list
>>> SG21_at_[hidden]
>>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
>>> Link to this post: http://lists.isocpp.org/sg21/2025/10/11352.php
>>>
>>>
>>> _______________________________________________
>> SG21 mailing list
>> SG21_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
>> Link to this post: http://lists.isocpp.org/sg21/2025/10/11422.php
>>
>>
>> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
>
>