Date: Tue, 14 Oct 2025 18:51:40 +0000
[Ryan]
* Sorry, this is a weakness of the medium -- what I'm saying is "no one is producing inline functions that are promised to be hardened in a legally binding way, such as in safety critical applications" -- precisely because putting hardening in source that is copy-pasta into a TU weakens the promise. It's the legally binding promise of hardening that's at stake. If your user is determined to defeat your library-level hardening, you cannot control that. Fighting your users is a battle that can't be won. You give them library hardening, and they either enable it or they don't.
Thanks for clarifying. I will have to ponder this for a while to see if I get the “legally binding” part of the conversation.
* What I'm saying is that hardened library writers do not rely on inlining.
I can see that as a hypothesis for the sake of the argument; but was it actually validated? The library writers I talk to don’t seem to support it. Furthermore, during the whole “quick enforce” debate in Tokyo, various people opined that “quick enforce” turns into very simple halting instructions for inlining purposes, a property so highly desirable that it was a deciding requirement for some.
-- Gaby
From: Ryan McDougall <mcdougall.ryan_at_[hidden]>
Sent: Tuesday, October 14, 2025 2:42 PM
To: Gabriel Dos Reis <gdr_at_[hidden]m>
Cc: sg15_at_[hidden]; Ville Voutilainen <ville.voutilainen_at_[hidden]>; sg21_at_[hidden]; John Spicer <jhs_at_[hidden]>
Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract checking for different libraries
Sorry, this is a weakness of the medium -- what I'm saying is "no one is producing inline functions that are promised to be hardened in a legally binding way, such as in safety critical applications" -- precisely because putting hardening in source that is copy-pasta into a TU weakens the promise. It's the legally binding promise of hardening that's at stake. If your user is determined to defeat your library-level hardening, you cannot control that. Fighting your users is a battle that can't be won. You give them library hardening, and they either enable it or they don't.
What I'm saying is that hardened library writers do not rely on inlining. The standard library occupies a bit of a unique space since it has (to try) to be all things to all people -- including the people who cannot imagine a reason why hardening should be turned off. Even if P2900 is somehow universally declared unsuitable for the standard library, this has no bearing on whether P2900 is necessary for Functional Safety. Neither the standard library nor GSL are the only or primary users of contracts.
Now I've already said enough on the matter, and for the sake of our readers I'm going to step away from the discussion for a while.
Cheers,
On Tue, Oct 14, 2025 at 11:08 AM Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
[Ryan]
* No one is shipping hardened inline contract-enabled functions.
I don’t know what you mean by this. Is that because contracts don’t exist in C++? Something else?
Organizations routinely ship running products (not debug, actual retail), with this https://github.com/microsoft/GSL , unsuppressed checking on; e.g. on gsl::span<T>::operator[]<https://github.com/microsoft/GSL/blob/main/include/gsl/span#L648>. You can see more in that file. The hardened standard library reflects parts of that. This isn’t debug exercise.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]<mailto:sg15-bounces_at_[hidden]>> On Behalf Of Ryan McDougall via SG15
Sent: Tuesday, October 14, 2025 1:53 PM
To: Ville Voutilainen <ville.voutilainen_at_[hidden]<mailto:ville.voutilainen_at_[hidden]>>
Cc: Ryan McDougall <mcdougall.ryan_at_[hidden]<mailto:mcdougall.ryan_at_[hidden]>>; sg21_at_[hidden]<mailto:sg21_at_[hidden]>; John Spicer <jhs_at_[hidden]<mailto:jhs_at_[hidden]>>; sg15_at_[hidden]<mailto:sg15_at_[hidden]>
Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract checking for different libraries
> there are existing and widely-employed deployment scenarios where application programmers use binary libraries and do not compile all their code.
And in these scenarios application programmers coordinate which versions of the binaries they link with. If they're surprised they didn't read the documentation.
We can excuse new learners and internet tinkerers for getting their clothes caught on the sharp edges, but that is nothing new to C++ -- and that's not the core audience for contracts.
Again it's regrettable that every new C++ feature causes complexity to increase, but the mere existence of sharp edges has not stopped other good and needed proposals.
> while it may be feasible for a hardened library implementation to make different contract evaluation semantics ABI-incompatible
Contracts are designed to be used in hardened libraries. If you want to make a toy project that is also incidentally binary only you're welcome to -- just make sure you document exactly what you're trying to achieve and why. You'll have to ship multiple binaries for the levels you intend to support.
It's always been easily to abuse an ABI -- when has the committee decided we need to prevent ABI abuse? That's a library implementor problem. We technically don't even support ABI compatibility!
> It is highly non-obvious to me what actual benefits we gain from having multiple inline function definitions in the same program
No one is shipping hardened inline contract-enabled functions.
No one is building mixed-mode hardened applications from header-only contract-enabled libraries.
When building a hardened library you tell the user how it should be used, and they use it the way you tell them, because they are building a hardened application. For those who are not interested in hardening, you tell them to either turn them all off or all on.
We have been building "modal" checking libraries for a very long time. No one turns NDEBUG on or off haphazardly.
These are problems on paper that don't exist outside the committee. If you want hardening, you follow the hardening rules. If you don't, then you basically don't care about contracts.
On Tue, Oct 14, 2025 at 10:18 AM Ville Voutilainen <ville.voutilainen_at_[hidden]<mailto:ville.voutilainen_at_[hidden]>> wrote:
On Tue, 14 Oct 2025 at 19:30, Ryan McDougall via SG21
<sg21_at_[hidden]<mailto:sg21_at_[hidden]>> wrote:
> I think what you're imagining is an internet-like ecosystem where small time developers and small time users are throwing things together without much training, documentation, or coordination.
I don't think we are. There is no lack of training, documentation, or
coordination, but there are existing and widely-employed deployment
scenarios where application programmers
use binary libraries and do not compile all their code. Quite a lot of
such scenarios, in fact.
>Contracts may offer a new facet, but the fundamental problem of sharing binaries is older than assert. It's just regular old 1970's library design: you have to produce multiple binaries for each target, be thoughtful about the ABI, and document how to use the ABI as intended.
Being thoughtful about the ABI doesn't seem to help much, considering
that while it may be feasible for a hardened standard library
implementation
to make different contract evaluation semantics ABI-incompatible, it
may well be less so feasible for other libraries and applications
combined
with such libraries.
> While some ODR violations are detectable, ODR is actually IFNDR -- so I don't think ODR is actually a preferable situation.
It is highly non-obvious to me what actual benefits we gain from
having multiple inline function definitions in the same program
compiled with different contract evaluation semantics, and what actual
practical problems we think we solve by making such
multiple definitions ODR-equivalent.
* Sorry, this is a weakness of the medium -- what I'm saying is "no one is producing inline functions that are promised to be hardened in a legally binding way, such as in safety critical applications" -- precisely because putting hardening in source that is copy-pasta into a TU weakens the promise. It's the legally binding promise of hardening that's at stake. If your user is determined to defeat your library-level hardening, you cannot control that. Fighting your users is a battle that can't be won. You give them library hardening, and they either enable it or they don't.
Thanks for clarifying. I will have to ponder this for a while to see if I get the “legally binding” part of the conversation.
* What I'm saying is that hardened library writers do not rely on inlining.
I can see that as a hypothesis for the sake of the argument; but was it actually validated? The library writers I talk to don’t seem to support it. Furthermore, during the whole “quick enforce” debate in Tokyo, various people opined that “quick enforce” turns into very simple halting instructions for inlining purposes, a property so highly desirable that it was a deciding requirement for some.
-- Gaby
From: Ryan McDougall <mcdougall.ryan_at_[hidden]>
Sent: Tuesday, October 14, 2025 2:42 PM
To: Gabriel Dos Reis <gdr_at_[hidden]m>
Cc: sg15_at_[hidden]; Ville Voutilainen <ville.voutilainen_at_[hidden]>; sg21_at_[hidden]; John Spicer <jhs_at_[hidden]>
Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract checking for different libraries
Sorry, this is a weakness of the medium -- what I'm saying is "no one is producing inline functions that are promised to be hardened in a legally binding way, such as in safety critical applications" -- precisely because putting hardening in source that is copy-pasta into a TU weakens the promise. It's the legally binding promise of hardening that's at stake. If your user is determined to defeat your library-level hardening, you cannot control that. Fighting your users is a battle that can't be won. You give them library hardening, and they either enable it or they don't.
What I'm saying is that hardened library writers do not rely on inlining. The standard library occupies a bit of a unique space since it has (to try) to be all things to all people -- including the people who cannot imagine a reason why hardening should be turned off. Even if P2900 is somehow universally declared unsuitable for the standard library, this has no bearing on whether P2900 is necessary for Functional Safety. Neither the standard library nor GSL are the only or primary users of contracts.
Now I've already said enough on the matter, and for the sake of our readers I'm going to step away from the discussion for a while.
Cheers,
On Tue, Oct 14, 2025 at 11:08 AM Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
[Ryan]
* No one is shipping hardened inline contract-enabled functions.
I don’t know what you mean by this. Is that because contracts don’t exist in C++? Something else?
Organizations routinely ship running products (not debug, actual retail), with this https://github.com/microsoft/GSL , unsuppressed checking on; e.g. on gsl::span<T>::operator[]<https://github.com/microsoft/GSL/blob/main/include/gsl/span#L648>. You can see more in that file. The hardened standard library reflects parts of that. This isn’t debug exercise.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]<mailto:sg15-bounces_at_[hidden]>> On Behalf Of Ryan McDougall via SG15
Sent: Tuesday, October 14, 2025 1:53 PM
To: Ville Voutilainen <ville.voutilainen_at_[hidden]<mailto:ville.voutilainen_at_[hidden]>>
Cc: Ryan McDougall <mcdougall.ryan_at_[hidden]<mailto:mcdougall.ryan_at_[hidden]>>; sg21_at_[hidden]<mailto:sg21_at_[hidden]>; John Spicer <jhs_at_[hidden]<mailto:jhs_at_[hidden]>>; sg15_at_[hidden]<mailto:sg15_at_[hidden]>
Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract checking for different libraries
> there are existing and widely-employed deployment scenarios where application programmers use binary libraries and do not compile all their code.
And in these scenarios application programmers coordinate which versions of the binaries they link with. If they're surprised they didn't read the documentation.
We can excuse new learners and internet tinkerers for getting their clothes caught on the sharp edges, but that is nothing new to C++ -- and that's not the core audience for contracts.
Again it's regrettable that every new C++ feature causes complexity to increase, but the mere existence of sharp edges has not stopped other good and needed proposals.
> while it may be feasible for a hardened library implementation to make different contract evaluation semantics ABI-incompatible
Contracts are designed to be used in hardened libraries. If you want to make a toy project that is also incidentally binary only you're welcome to -- just make sure you document exactly what you're trying to achieve and why. You'll have to ship multiple binaries for the levels you intend to support.
It's always been easily to abuse an ABI -- when has the committee decided we need to prevent ABI abuse? That's a library implementor problem. We technically don't even support ABI compatibility!
> It is highly non-obvious to me what actual benefits we gain from having multiple inline function definitions in the same program
No one is shipping hardened inline contract-enabled functions.
No one is building mixed-mode hardened applications from header-only contract-enabled libraries.
When building a hardened library you tell the user how it should be used, and they use it the way you tell them, because they are building a hardened application. For those who are not interested in hardening, you tell them to either turn them all off or all on.
We have been building "modal" checking libraries for a very long time. No one turns NDEBUG on or off haphazardly.
These are problems on paper that don't exist outside the committee. If you want hardening, you follow the hardening rules. If you don't, then you basically don't care about contracts.
On Tue, Oct 14, 2025 at 10:18 AM Ville Voutilainen <ville.voutilainen_at_[hidden]<mailto:ville.voutilainen_at_[hidden]>> wrote:
On Tue, 14 Oct 2025 at 19:30, Ryan McDougall via SG21
<sg21_at_[hidden]<mailto:sg21_at_[hidden]>> wrote:
> I think what you're imagining is an internet-like ecosystem where small time developers and small time users are throwing things together without much training, documentation, or coordination.
I don't think we are. There is no lack of training, documentation, or
coordination, but there are existing and widely-employed deployment
scenarios where application programmers
use binary libraries and do not compile all their code. Quite a lot of
such scenarios, in fact.
>Contracts may offer a new facet, but the fundamental problem of sharing binaries is older than assert. It's just regular old 1970's library design: you have to produce multiple binaries for each target, be thoughtful about the ABI, and document how to use the ABI as intended.
Being thoughtful about the ABI doesn't seem to help much, considering
that while it may be feasible for a hardened standard library
implementation
to make different contract evaluation semantics ABI-incompatible, it
may well be less so feasible for other libraries and applications
combined
with such libraries.
> While some ODR violations are detectable, ODR is actually IFNDR -- so I don't think ODR is actually a preferable situation.
It is highly non-obvious to me what actual benefits we gain from
having multiple inline function definitions in the same program
compiled with different contract evaluation semantics, and what actual
practical problems we think we solve by making such
multiple definitions ODR-equivalent.
Received on 2025-10-14 18:51:47