C++ Logo

sg15

Advanced search

Re: [isocpp-sg21] Contracts and tooling

From: Timur Doumler <cpp_at_[hidden]>
Date: Thu, 9 Nov 2023 12:44:20 -1000
Hi Tom,

Thanks. It has always been our intention to reach out to SG15, present the Contracts MVP to them, and give them the chance to review it with tooling considerations in mind.

However, my original plan was to first let SG21 plug the remaining design holes, and then reach out to SG15 as soon as we have achieved that, i.e. we don't have any of the yellow "TO DO" boxes left in P2900 (our Contracts working paper). I think we're not that far away from that and we'll get there at some point between now and Tokyo.

Are you OK with this general plan, or do you have a strong preference for presenting P2900 in SG15 on a more urgent schedule?

Cheers,
Timur

On 9 Nov 2023, at 09:59, Tom Honermann via SG21 <sg21_at_[hidden]> wrote:



Cross-posting to SG15 and SG21.

My goal with this email is to encourage collaboration between SG21 (Contracts) and SG15 (Tooling) on the contracts MVP well in advance of the design being presented and potentially approved by EWG.

SG23 (Safety and Security) discussed P2947 (Contracts must avoid disclosing sensitive information) yesterday and agreed that SG15 (Tooling) should address these concerns.

Some regular attendees of SG15 have expressed concerns that a contracts design (the MVP) might be accepted for C++26 without adequate tooling consideration thereby potentially leading to a situation like we have now with modules where we have a language feature with significant adoption challenges. I share some of these concerns.

The following are concerns that I have in mind that are relevant to tooling and that I believe will benefit from SG15 involvement.

  1. Use of contracts in production environments:
    1. Such use will be constrained, independently of the costs of the contract checks themselves, if enablement imposes considerable overhead.
    2. Such use will be constrained if enablement requires rebuilding code for different build modes (ignore, observe, enforce) or for different enablement labels (default, audit).
    3. Such use will be constrained for applications that have dependencies on packages provided by package managers. Package managers are unlikely to provide separate contract-disabled and contract-enabled builds, nor are system package managers likely to provide multiple builds (they don't provide separate assert-disabled and assert-enabled builds today for example). Use in production will require means to provide packages that, at run-time, can have any of the contract semantics (ignore, observe, enforce) enabled at load-time. This capability would require very low overhead means to enable such selection at load-time. Existing linker technologies like the GNU ifunc extension to ELF might pave the way to low overhead solutions.
  2. Discoverability of contract check labels/levels, particularly in situations where contract checks can be dynamically enabled.
  3. Protection of sensitive information per P2947.

Please reply with any additional concerns. I believe papers, probably targeting SG15 and the ecosystem IS, will eventually be desired.

Tom.

_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/sg15

Received on 2023-11-09 22:44:29