We could provide standardised labels in the standard library. That way you
don't have to guess what such labels do.

pe 24. lokak. 2025 klo 12.12 Jonas Persson via SG21 <sg21_at_[hidden]>
kirjoitti:

> On 10/24/25 00:16, Herb Sutter via SG21 wrote:
> >
> > Summarizing: If idx is computed by the program, *and* we’re in
> > security-critical code (such as we want a guaranteed-hardened standard
> > library), we want this to be an assertion that is enforced in
> > production. It’s true that we can’t yet express that in C++26
> > contracts, and that the labels extension would let us express it
> > (among other things).
> >
> Labels will not solve the full problem. It may give us the ability to
> force a runtime assertion in production, but it does not in practice
> clearly separate ignorable and non-ignorable checks.
> A label can turn contracts on and off based on any kinds of sources
> including build flags.
> Even with labels we must be able to mark the contracts as guaranteed or
> not.
> Where guaranteed means that it will only pass if its condition is true,
> not because any label property.
>
> > *From:*SG21 <sg21-bounces_at_[hidden]> *On Behalf Of *Tom
> > Honermann via SG21
> > *Sent:* Thursday, October 23, 2025 9:21 AM
> > *To:* sg21_at_[hidden]; Gašper Ažman <gasper.azman_at_[hidden]>
> > *Cc:* Tom Honermann <tom_at_[hidden]>; Harald Achitz
> > <harald_at_[hidden]>; sg15_at_[hidden]
> > *Subject:* Re: [isocpp-sg21] [isocpp-sg15] P3835 -- Different contract
> > checking for different libraries
> >
> > On 10/22/25 10:26 AM, John Spicer via SG21 wrote:
> >
> > That still fails to do what i want, which is to have the library
> > provide know that the semantic they choose will be the one used
> > when the program is linked.
> >
> > The following question is, again, intended as a serious one.
> >
> > Why do you want to use contracts to provide that guarantee?
> >
> > From my perspective, an unconditional-always-enforce contract semantic
> > changes a function that has a narrow contract into a function that has
> > a wide contract (or at least a wider contract subject to contracts
> > that are actually expressible in the language). Contracts aren't
> > needed to do that; we can express wider contracts in code today. Is
> > the desire based on wanting integration with a contract violation
> > handler? Or a desire to express hardened preconditions in the function
> > interface so that they are available for static analysis or
> > caller-side optimization?
> >
> > Assuming those capture your motivation, how far would support for a
> > syntax like the following go towards satisfying your desire?
> >
> > int* find(int *begin, int *end, int item)
> > pre *hardened* (begin != nullptr) // Hardened preconditions;
> > pre *hardened* (end != nullptr) // always evaluated with a
> > pre *hardened* (begin <= end) // terminating contract semantic.
> > pre (is_sorted(begin, end) // Not a hardened precondition.
> > ;
> >
> > It also sounds like this is mostly a variant of runtime semantic
> > selection, which requires the code for all possible semantic
> > varients to be emitted, which is a non-starter for most production
> > code.
> >
> > For what it is worth, I agree that is a non-starter for most
> > production code with the linkers and loaders in use today.
> >
> > This is a bit of a tangent, but my expectation, based on post link
> > optimization work I'm aware of but can't talk about, is that future
> > linkers and loaders will be able to support optimizing at load-time
> > based on a load-time selected contract semantic (similar to JIT
> > enablement of Java assertions by JVMs). I can't promise that such
> > technologies will ever be deployed of course or on any meaningful
> > timeline. I want to ensure the C++ standard does not prohibit use of
> > such future optimization possibilities by requiring a compile-time
> > selected semantic by default (I'm ok with an explicit opt-in as in the
> > example above).
> >
> > Tom.
> >
> > John.
> >
> >
> >
> > On Oct 20, 2025, at 7:33 AM, Gašper Ažman
> > <gasper.azman_at_[hidden]> <mailto:gasper.azman_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/
> > <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
> > <
> https://lists.isocpp.org/mailman/listinfo.cgi/sg21>
> > Link to this post:
> >
> http://lists.isocpp.org/sg21/2025/10/11351.php
> > <
> http://lists.isocpp.org/sg21/2025/10/11351.php>
> >
> > _______________________________________________
> > SG21 mailing list
> > SG21_at_[hidden]
> > Subscription:
> >
> https://lists.isocpp.org/mailman/listinfo.cgi/sg21
> > <
> https://lists.isocpp.org/mailman/listinfo.cgi/sg21>
> > Link to this post:
> > http://lists.isocpp.org/sg21/2025/10/11352.php
> > <http://lists.isocpp.org/sg21/2025/10/11352.php>
> >
> > _______________________________________________
> > SG21 mailing list
> > SG21_at_[hidden]
> > Subscription:
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg21
> > <https://lists.isocpp.org/mailman/listinfo.cgi/sg21>
> > Link to this post:
> > http://lists.isocpp.org/sg21/2025/10/11422.php
> > <http://lists.isocpp.org/sg21/2025/10/11422.php>
> >
> >
> >
> > _______________________________________________
> >
> > SG21 mailing list
> >
> > SG21_at_[hidden]
> >
> > Subscription:https://lists.isocpp.org/mailman/listinfo.cgi/sg21 <
> https://lists.isocpp.org/mailman/listinfo.cgi/sg21>
> >
> > Link to this post:http://lists.isocpp.org/sg21/2025/10/11687.php <
> http://lists.isocpp.org/sg21/2025/10/11687.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/11734.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/11746.php
>