Date: Wed, 24 Sep 2025 19:05:54 +0300
On Wed, 24 Sept 2025 at 17:35, Peter Bindels via SG21
<sg21_at_[hidden]> wrote:
> First of, the point of view of the standard. As far as the standard is concerned, the compiler outputs a binary that is able to evaluate all contract evaluation modes that should be possible (pending a compiler-specific mechanism to choose this).
I do not recognize this description from our specification.
>The actual contract evaluation mode is then selected in a compiler-specific mechanism from among those that are available. When such a contract then fails and goes to the contract violation handler, it will go to the globally set contract violation handler. That's either the default, or whichever your program provides, but only one at link time. Usual link time rules work here.
That seems to be assuming a particular way programs are linked.
> Compilers (and linkers) can do smarter things though. To start, they can use knowledge of invariants and function preconditions to optimize out checks to functions called from this one. They can emit function entry points that are beyond the pre-check of the function (see P3267 $3.3). They can offer compiler flags that omit the ability to skip a contract, or omit the ability to not terminate when it fails. This allows the compiler to emit faster code and optimize better, at the expense of requiring all of its output to be compiled in the same way.
What does that last sentence mean?
> If you want the maximally compatible variant, use the first strategy. If you want a faster implementation, use it in the way that that implementation specifies you do. ABIs can be created and modified to make any violation a linker failure, but the language doesn't at this point say anything about how the build tools and compiler optimize. There are papers scheduled for C++29 (P3400 for example) that do go into these details, so for P3400 this is definitely a point to bring up.
Sounds quite ttheoretical.
>> And is it even possible to have different contract handlers set, in dependencies, or do people make that up?
> I have no idea where such an idea would come from.
That a particular piece of code would like to define how violations in
it or in the code it calls are handled? The section "Local Violation
Handlers"
in P3400?
>> What will, for example, Linux distributions add to their build, will it be implementation defined? And I can tell from the binary in the system what it is.
> P3267 provides some approaches that work.
Approaches that work, or are theoretized to work?
> > Except on Windows you might, which is yet another unanswered question in the face of lack of both implementation and deployment experience.
> It would help if the prevalent Windows compiler would implement contracts so that we could get this experience. Sadly, it is not available cross platform nor open source, making it impossible for others to do this for them.
I'm under the impression that an open-source compiler that targets the
same ABIs and builds the same kind of DLLs as the prevalent one
is available for such experiments.
<sg21_at_[hidden]> wrote:
> First of, the point of view of the standard. As far as the standard is concerned, the compiler outputs a binary that is able to evaluate all contract evaluation modes that should be possible (pending a compiler-specific mechanism to choose this).
I do not recognize this description from our specification.
>The actual contract evaluation mode is then selected in a compiler-specific mechanism from among those that are available. When such a contract then fails and goes to the contract violation handler, it will go to the globally set contract violation handler. That's either the default, or whichever your program provides, but only one at link time. Usual link time rules work here.
That seems to be assuming a particular way programs are linked.
> Compilers (and linkers) can do smarter things though. To start, they can use knowledge of invariants and function preconditions to optimize out checks to functions called from this one. They can emit function entry points that are beyond the pre-check of the function (see P3267 $3.3). They can offer compiler flags that omit the ability to skip a contract, or omit the ability to not terminate when it fails. This allows the compiler to emit faster code and optimize better, at the expense of requiring all of its output to be compiled in the same way.
What does that last sentence mean?
> If you want the maximally compatible variant, use the first strategy. If you want a faster implementation, use it in the way that that implementation specifies you do. ABIs can be created and modified to make any violation a linker failure, but the language doesn't at this point say anything about how the build tools and compiler optimize. There are papers scheduled for C++29 (P3400 for example) that do go into these details, so for P3400 this is definitely a point to bring up.
Sounds quite ttheoretical.
>> And is it even possible to have different contract handlers set, in dependencies, or do people make that up?
> I have no idea where such an idea would come from.
That a particular piece of code would like to define how violations in
it or in the code it calls are handled? The section "Local Violation
Handlers"
in P3400?
>> What will, for example, Linux distributions add to their build, will it be implementation defined? And I can tell from the binary in the system what it is.
> P3267 provides some approaches that work.
Approaches that work, or are theoretized to work?
> > Except on Windows you might, which is yet another unanswered question in the face of lack of both implementation and deployment experience.
> It would help if the prevalent Windows compiler would implement contracts so that we could get this experience. Sadly, it is not available cross platform nor open source, making it impossible for others to do this for them.
I'm under the impression that an open-source compiler that targets the
same ABIs and builds the same kind of DLLs as the prevalent one
is available for such experiments.
Received on 2025-09-24 16:06:08