172. Safety, Rust, Swift, WG21 papers, Contracts

With Bjarne Stroustrup, Gianluca Delfino, Frances Buontempo, Jody Hagins, Csaba Ráduly et al.

Reddit: https://www.reddit.com/r/cpp/comments/1e8mjsr/c_club_172_safety_rust_swift_wg21_papers/

Media

Video

https://youtu.be/dWz6s1oS2RY

Podcast

https://redcircle.com/shows/0835997e-47ec-438e-b6ae-0b390966aa7e/episodes/bc596ce4-8136-468e-864a-4fc8f5d9c82c

Powered by RedCircle

Feedback

Software industry regulation

Robert:

you quote a prediction regarding regulation on software engineering, and then ridicule it with a laughing track. A laughing track, like we were watching a sitcom! This was really undignified. Especially, since I assess the prediction to have some truth to it: It is already starting to happen. Customers start putting pressure on software developers to follow rules and fulfill regulatory requirements, so they won’t be liable if the software they bought causes damages.

Having worked as a consultant in many large firms over the years, I’ve seen things. Code written by contractors who don’t give two shits about quality of their work (current place being a rare exception). The entire defective and badly designed systems produced by outsourced programmers ruining peoples' lives (like the UK Post Office defective Horizon system produced by Fujitsu where software bugs were ignored and covered up, have a read). This has been happening for many years and is still happening. And just wait for the onslaught of AI-generated code containing subtle bugs. So forgive me if I’m not too optimistic here.

Swift as C++ successor

Redditor pjmlp on Swift as C++ successor:

Regarding their Swift’s remark, it is straight there in Apple’s official documentation, and 2023 talks by Apple employees.

Swift is a successor to the C, C++, and Objective-C languages. It includes low-level primitives such as types, flow control, and operators. It also provides object-oriented features such as classes, protocols, and generics, giving Cocoa and Cocoa Touch developers the performance and power they demand.

White House report on memory safety (cont.)

“While formal methods have been studied for decades, their deployment remains limited; further innovation in approaches to make formal methods widely accessible is vital to accelerate their broad adoption.” — White House

Well gosh. I applied to US research programs with an interest in formal methods and was rejected absolutely across the board. Good luck to you.

I’ve been in the industry long enough to know that there’s a significant number of devs that will refuse to adopt new language standards. I’m 100% confident there are C++ devs still writing C++03 style code. Both because they simply haven’t taken the time to know what’s in C++11 and later and because they have some mistrust and even irrational fears about enabling C++11 and later feature sets on their codebases.

It’s unfortunate that Mr. Sutter still throws C and C++ into one bucket, and then concludes that bounds checking is a problem that "we" have. This data really needs to be split into three categories: C, C++ as written by people that will never progress beyond C++98, and C++ as written by people that use modern tools to begin with. The first two groups should be considered as being outside the target audience for any kind of safety initiative.

C++ has too much undefined behaviour to become a safe programming language in the foreseeable future. One way or another, all the C++ experts cited here agree on that.

<…​> the narrative of C++ as inherently unsafe oversimplifies the situation. The language has undergone substantial evolution, with modern iterations emphasizing safer memory practices without compromising the language’s core principles of efficiency and control.

The journey toward making C++ a safer language is complex and fraught with challenges. However, the discussions and proposals led by Stroustrup and supported by the broader C++ community suggest a forward path that respects the language’s legacy while addressing the pressing needs of modern computing.

Right now, many of the articles about modern C++ and memory safe C++ end up preaching to the choir. The advice doesn’t reach all corners of industry, and many places in academia are stuck in their ways. If you go to small CS programs at small schools, you will frequently find people learning C++ as C++ 98 or C++03, so they see C++ as “C with Classes and Templates” or “Java without a GC”.

Rust and C++ interop

Old codebases need maintenance. It is a technical debt that comes due eventually. The most direct approach to improve security and quality of C++ project is to migrate to more recent C++ specification and compilers. Adding layer of "rust" to old codebases is not going to make them safer or better.

See also: Mixing Swift and C++

Mixing C++ and Rust for Fun and Profit

KDAB:

Why Rust isn’t killing C++

Society’s Backend (Great website name!) by Logan Thorneloe, an ML engineer at Google.

<…​> the internet likes to perpetuate the myth that C++ is a soon-to-be-dead language. I’ve seen many people say not to learn C++ because Rust can do basically everything C++ can do but is much easier to work with and almost guaranteed to be memory safe. This narrative is especially harmful for new developers who focus primarily on what languages they should gain experience in. This causes them to write off C++ which I think is a huge mistake because it’s actually one of the best languages for new developers to learn.

Unsafe Rust in the Wild: Notes on the Current State of Unsafe Rust

https://foundation.rust-lang.org/news/unsafe-rust-in-the-wild-notes-on-the-current-state-of-unsafe-rust/

Slashdot: Rust Foundation Reports 20% of Rust Crates Use 'Unsafe' Keyword

Leaving Rust gamedev after 3 years

https://loglog.games/blog/leaving-rust-gamedev/ (HN, Reddit)

Learning Rust is an interesting experience, because while many things initially feel like "this is a special problem only I’m having", later one realizes that there’s a few fundamental patterns that are universal, and that everyone learning has to re-discover and internalize in order to be productive. <…​> there is an overwhelming force in the Rust community that when anyone mentions they’re having problems with Rust the language on a fundamental level, the answer is "you just don’t get it yet, I promise once you get good enough things will make sense" <…​> The problem you’re having is only a problem because you haven’t tried hard enough.

This certainly sounds familiar and not at all specific to Rust.

Why all the 'hate' for C++?

https://www.reddit.com/r/cpp/comments/1czmjhj/why_all_the_hate_for_c/

The vast majority of opinions that people espouse relate to their need to justify their decisions and should be of no interest to you. They are not trying to help you, they are trying to help themselves. Carry on. Good luck.

Google Crubit

Crubit: C++/Rust Bidirectional Interop Tool

Swift for C++ Practitioners

A series of articles by Doug Gregor

WG21 Mailing Apr 2024

Papers

Reddit

Static Exception Specifications

P3166R0 by Lewis Baker

P2900R6 May Be Minimal, but It Is Not Viable

P3173R0 by Gabriel Dos Reis, Microsoft

Without adequate limitation on undefined behavior in the evaluation of contract assertions, Microsoft considers the Contracts facility not viable in the contemporary environments where C++ is used.

Contracts facility that fails to adequately support efficient use with virtual functions and pointer to functions is woefully inadequate and unready for prime use, and inclusion in C26 in particular. Microsoft recommends against the inclusion of P2900R6 in C26.

Microsoft recommends against P2900R6 without applications in the Standard Library, in particular in the algorithm section, and field experience.

More papers from May 2024 mailing

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/#mailing2024-05 (Reddit)

A framework for Profiles development

https://wg21.link/p3274r0 by Bjarne Stroustrup

Undefined and erroneous behaviour are contract violations

https://wg21.link/p3100r0 by Timur Doumler et al.

In this paper, we propose to specify undefined behaviour that manifests at runtime to be a contract violation.

Our proposed framework replaces the concept of erroneous behaviour introduced in P2795R5 and paves the way for a safer and more secure C++ Standard.

As we will show in this paper, the semantics provided by erroneous behaviour are essentially a subset of the semantics that the Contracts framework provides. We can therefore entirely subsume erroneous behaviour into contract violation handling.

This makes C++ safety and UB handling dependent on Contracts, which I thought was an opt-in feature? With this proposal we seem to get automatic implicit contracts everywhere. Not sure I like this. Especially given how contentious the Contracts feature is in the Committee.

An alternate proposal for naming contract semantics

https://wg21.link/p3238r0 by Ville Voutilainen

The current naming of contract semantics more or less follows the form

<…​> the trueness of a predicate

and we use the words 'ignore', 'enforce', 'observe', and ostensibly, 'quick_enforce' for the blank. This proposal suggests that we should use the form

A contract violation is treated as <…​>

and that we use the words 'ignored', 'enforced', 'observed' and 'erroneous' for the blank.

And here is an UNO reverse card:

The more significant part proposed here is that a contract with the semantic where a contract violation causes instant termination without calling a violation handler is simply treated as Erroneous Behavior, with the "fallback" defined behavior being calling the violation handler.

Contracts for C++

https://wg21.link/p2900r7 by Joshua Berne, Timur Doumler, Andrzej Krzemieński

  • The observe semantic will invoke the contract-violation handler; if the contract-violation handler returns normally, program execution will continue from the point of evaluation of the contract assertion.
  • The enforce semantic will invoke the contract-violation handler; if the contract-violation handler returns normally, the program is terminated in an implementation-defined fashion.
  • The quick_enforce semantic will not invoke the contract-violation handler, but instead immediately terminate the program in an implementation-defined fashion.

C++ Contracts and Coroutines

https://wg21.link/p3251r0 by Peter Bindels

The paper is not required for the MVP; it defines behavior for a currently ill-formed construct. It does have very little impact on the contents as it mostly provides a rationale and approach for the reason not to forbid coroutines to have contracts, and as such it could be considered for the C++26 deadline.

Contract testing support

https://wg21.link/p3183r1 by Bengt Gustafsson

Ship Contracts in a TS

https://wg21.link/p3265r1 by Ville Voutilainen

Do Not Ship Contracts as a TS

https://wg21.link/p3269r0 by Timur Doumler, John Spicer

P2900 Is Superior to a Contracts TS

https://wg21.link/p3276r0 by Joshua Berne, Steve Downey, Jake Fevold, Mungo Gill, Rostislav Khlebnikov, John Lakos, and Alisdair Meredith

To TS or not to TS: that is the question

https://wg21.link/p4000r0 by Michael Wong, H. Hinnant, R. Orr, B. Stroustrup, D. Vandevoorde

C++26 Needs Contract Checking

https://wg21.link/p3297r0 by Ryan McDougall, Jean-Francois Campeau, Christian Eltzschig, Mathias Kraus, Pez Zarifian

Not sure Contracts will magically solve all security problems in C++.

Expansion statements

https://wg21.link/p1306r2 by Dan Katz, Andrew Sutton, Sam Goodrick, Daveed Vandevoorde

Code Injection with Token Sequences

https://wg21.link/p3294r0 by Barry Revzin, Andrei Alexandrescu (NVIDIA), Daveed Vandevoorde

Generative Extensions for Reflection

https://wg21.link/p3157r1 by Andrei Alexandrescu, Barry Revzin, Bryce Lelbach, Michael Garland

The metaclasses paper has been marked as abandoned: https://github.com/cplusplus/papers/issues/403

A unified syntax for Pattern Matching and Contracts when introducing a new name

https://wg21.link/p3249r0 by Ran Regev

Pointer Tagging

https://wg21.link/p3125r0 by Hana Dusíková

This paper proposes a library based design with "magical functions" to store and retrieve information into bits of pointers which are not significant to the pointer’s address, and to inform developers about how many such bits are available.

Reserve identifiers preceded by @ for non-ignorable annotation tokens

https://wg21.link/p3254r0 by Brian Bi

Mastodon: Programming

https://chaosfem.tw/@rooster/112335366409013731

I think programming is like running a dishwasher. It always takes longer than you think and some stuff is never as clean as you expected it to be.

Jessica @rooster@chaosfem.tw

Burn-out

Via Dare Obasanjo and Ivor Hewitt

https://mas.to/@carnage4life/112439740083930142

dyno burnout