Date: Mon, 20 Oct 2025 12:33:31 +0100
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
>
>
>
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
>
>
>
Received on 2025-10-20 11:33:49
