Date: Tue, 14 Oct 2025 16:43:09 -0400
On 10/14/25 4:35 PM, Gabriel Dos Reis via SG21 wrote:
> The existing practice doesn't demonstrate any of that.
I'm afraid I don't know precisely what you are referring to by "any of
that".
If you mean that libc++ isn't specifically calling the C++26 contract
violation handler, I agree. But I can clearly see that a change to do so
would involve a trivial change to the libc++ source code.
Tom.
>
> -- Gaby
>
>
>
> ------------------------------------------------------------------------
> *From:* Tom Honermann <tom_at_[hidden]>
> *Sent:* Tuesday, October 14, 2025 4:32:42 PM
> *To:* sg21_at_[hidden] <sg21_at_[hidden]>;
> sg15_at_[hidden] <sg15_at_[hidden]>
> *Cc:* Gabriel Dos Reis <gdr_at_[hidden]>
> *Subject:* Re: [isocpp-sg21] [isocpp-sg15] P3835 -- Different contract
> checking for different libraries
> On 10/14/25 4:17 PM, Gabriel Dos Reis via SG21 wrote:
>>
>> [Tom]
>>
>> * They are, or will be, once either of P3290 (Integrating Existing
>> Assertions With Contracts) <https://wg21.link/p3290> or P3400
>> (Specifying Contract Assertion Properties with Labels)
>> <https://wg21.link/p3400> is adopted.
>>
>> If that conjecture is true, then I would recommend to wait for those
>> papers to be implemented, with deployment experience and adopted
>> before phrasing the hardened standard library in terms of contracts.
>>
> I find the existing practice as demonstrated by libc++ both sufficient
> and compelling. I accept that you may feel differently.
>
> Tom.
>
>> -- Gaby
>>
>> *From:*SG15 <sg15-bounces_at_[hidden]>
>> <mailto:sg15-bounces_at_[hidden]> *On Behalf Of *Tom Honermann
>> via SG15
>> *Sent:* Tuesday, October 14, 2025 4:00 PM
>> *To:* sg21_at_[hidden] <mailto:sg21_at_[hidden]>; Ville
>> Voutilainen via SG15 <sg15_at_[hidden]>
>> <mailto:sg15_at_[hidden]>
>> *Cc:* Tom Honermann <tom_at_[hidden]> <mailto:tom_at_[hidden]>
>> *Subject:* Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different
>> contract checking for different libraries
>>
>> On 10/14/25 3:21 PM, Ran Regev via SG21 wrote:
>>
>> On Tue, Oct 14, 2025, 21:47 Ville Voutilainen via SG15
>> <sg15_at_[hidden] <mailto:sg15_at_[hidden]>> wrote:
>>
>> On Tue, 14 Oct 2025 at 21:42, Ryan McDougall
>> <mcdougall.ryan_at_[hidden] <mailto:mcdougall.ryan_at_[hidden]>>
>> wrote:
>> >
>> > And there are existing deployments where it's not desired
>> and not a requirement...
>>
>> That doesn't mean that hardening should be possible to be
>> turned off
>> by a contract evaluation semantic choice
>>
>> One of the fundamental aspects of p2900 is that the person who
>> write the contract is not the one who selects the semantics for
>> the application.
>>
>> Is this aspect of contracts aligned with hardened libraries
>> needs? The discussion seems to reveal that not. And therefore the
>> draft paper mentioned earlier seems to be correct - contracts are
>> not good fit for standard library hardening.
>>
>> They are, or will be, once either of P3290 (Integrating Existing
>> Assertions With Contracts) <https://wg21.link/p3290> or P3400
>> (Specifying Contract Assertion Properties with Labels)
>> <https://wg21.link/p3400> is adopted.
>>
>> Tom.
>>
>> applying to other code. Or more in the opposite direction, it doesn't
>> mean that the choice of a contract evaluation semantic
>> for other code should turn the hardening off.
>>
>>
>> > The original sin is thinking that any one engineer knows all
>> domains and anything that doesn't fit their preconceptions is
>> universally wrong.
>>
>> Funny, you seem to be the only person in this discussion stating that
>> something is universally wrong, or otherwise I have misunderstood
>> what you think "patently false" means.
>>
>> >P2900 has been in development for a long time, and is useful and
>> needed. The idea it's "unsafe" shows a lack of understanding of
>> what that word means.
>>
>> Oh sure, it's a likely story that the critics of P2900 simply
>> misunderstand something. In fact, a story so unlikely that it's safe
>> to say it's patently false.
>> _______________________________________________
>> SG15 mailing list
>> SG15_at_[hidden] <mailto:SG15_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>> <https://lists.isocpp.org/mailman/listinfo.cgi/sg15>
>>
>>
>>
>> _______________________________________________
>> SG21 mailing list
>> SG21_at_[hidden] <mailto: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/11273.php <http://lists.isocpp.org/sg21/2025/10/11273.php>
>>
>> _______________________________________________
>> SG21 mailing list
>> SG21_at_[hidden] <mailto: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/11281.php <http://lists.isocpp.org/sg21/2025/10/11281.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/11286.php
> The existing practice doesn't demonstrate any of that.
I'm afraid I don't know precisely what you are referring to by "any of
that".
If you mean that libc++ isn't specifically calling the C++26 contract
violation handler, I agree. But I can clearly see that a change to do so
would involve a trivial change to the libc++ source code.
Tom.
>
> -- Gaby
>
>
>
> ------------------------------------------------------------------------
> *From:* Tom Honermann <tom_at_[hidden]>
> *Sent:* Tuesday, October 14, 2025 4:32:42 PM
> *To:* sg21_at_[hidden] <sg21_at_[hidden]>;
> sg15_at_[hidden] <sg15_at_[hidden]>
> *Cc:* Gabriel Dos Reis <gdr_at_[hidden]>
> *Subject:* Re: [isocpp-sg21] [isocpp-sg15] P3835 -- Different contract
> checking for different libraries
> On 10/14/25 4:17 PM, Gabriel Dos Reis via SG21 wrote:
>>
>> [Tom]
>>
>> * They are, or will be, once either of P3290 (Integrating Existing
>> Assertions With Contracts) <https://wg21.link/p3290> or P3400
>> (Specifying Contract Assertion Properties with Labels)
>> <https://wg21.link/p3400> is adopted.
>>
>> If that conjecture is true, then I would recommend to wait for those
>> papers to be implemented, with deployment experience and adopted
>> before phrasing the hardened standard library in terms of contracts.
>>
> I find the existing practice as demonstrated by libc++ both sufficient
> and compelling. I accept that you may feel differently.
>
> Tom.
>
>> -- Gaby
>>
>> *From:*SG15 <sg15-bounces_at_[hidden]>
>> <mailto:sg15-bounces_at_[hidden]> *On Behalf Of *Tom Honermann
>> via SG15
>> *Sent:* Tuesday, October 14, 2025 4:00 PM
>> *To:* sg21_at_[hidden] <mailto:sg21_at_[hidden]>; Ville
>> Voutilainen via SG15 <sg15_at_[hidden]>
>> <mailto:sg15_at_[hidden]>
>> *Cc:* Tom Honermann <tom_at_[hidden]> <mailto:tom_at_[hidden]>
>> *Subject:* Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different
>> contract checking for different libraries
>>
>> On 10/14/25 3:21 PM, Ran Regev via SG21 wrote:
>>
>> On Tue, Oct 14, 2025, 21:47 Ville Voutilainen via SG15
>> <sg15_at_[hidden] <mailto:sg15_at_[hidden]>> wrote:
>>
>> On Tue, 14 Oct 2025 at 21:42, Ryan McDougall
>> <mcdougall.ryan_at_[hidden] <mailto:mcdougall.ryan_at_[hidden]>>
>> wrote:
>> >
>> > And there are existing deployments where it's not desired
>> and not a requirement...
>>
>> That doesn't mean that hardening should be possible to be
>> turned off
>> by a contract evaluation semantic choice
>>
>> One of the fundamental aspects of p2900 is that the person who
>> write the contract is not the one who selects the semantics for
>> the application.
>>
>> Is this aspect of contracts aligned with hardened libraries
>> needs? The discussion seems to reveal that not. And therefore the
>> draft paper mentioned earlier seems to be correct - contracts are
>> not good fit for standard library hardening.
>>
>> They are, or will be, once either of P3290 (Integrating Existing
>> Assertions With Contracts) <https://wg21.link/p3290> or P3400
>> (Specifying Contract Assertion Properties with Labels)
>> <https://wg21.link/p3400> is adopted.
>>
>> Tom.
>>
>> applying to other code. Or more in the opposite direction, it doesn't
>> mean that the choice of a contract evaluation semantic
>> for other code should turn the hardening off.
>>
>>
>> > The original sin is thinking that any one engineer knows all
>> domains and anything that doesn't fit their preconceptions is
>> universally wrong.
>>
>> Funny, you seem to be the only person in this discussion stating that
>> something is universally wrong, or otherwise I have misunderstood
>> what you think "patently false" means.
>>
>> >P2900 has been in development for a long time, and is useful and
>> needed. The idea it's "unsafe" shows a lack of understanding of
>> what that word means.
>>
>> Oh sure, it's a likely story that the critics of P2900 simply
>> misunderstand something. In fact, a story so unlikely that it's safe
>> to say it's patently false.
>> _______________________________________________
>> SG15 mailing list
>> SG15_at_[hidden] <mailto:SG15_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>> <https://lists.isocpp.org/mailman/listinfo.cgi/sg15>
>>
>>
>>
>> _______________________________________________
>> SG21 mailing list
>> SG21_at_[hidden] <mailto: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/11273.php <http://lists.isocpp.org/sg21/2025/10/11273.php>
>>
>> _______________________________________________
>> SG21 mailing list
>> SG21_at_[hidden] <mailto: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/11281.php <http://lists.isocpp.org/sg21/2025/10/11281.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/11286.php
Received on 2025-10-14 20:43:11
