[arnsholt]

In 2014 John Regehr and colleagues suggested what he called Friendly C[0], in an attempt to salvage C from UB. About bit more than a year later, he concluded that the project wasn't really feasible because people couldn't agree on the details of what Friendly C should be.[1]

In the second post, there's an interesting comment towards the end:

> Luckily there’s an easy away forward, which is to skip the step where we try to get consensus. Rather, an influential group such as the Android team could create a friendly C dialect and use it to build the C code (or at least the security-sensitive C code) in their project. My guess is that if they did a good job choosing the dialect, others would start to use it, and at some point it becomes important enough that the broader compiler community can start to help figure out how to better optimize Friendly C without breaking its guarantees, and maybe eventually the thing even gets standardized. There’s precedent for organizations providing friendly semantics; Microsoft, for example, provides stronger-than-specified semantics for volatile variables by default on platforms other than ARM.

I would argue that this has happened, but not quite in the way he expected. Google (and others) has chosen a way forward, but rather than somehow fixing C they have chosen Rust. And from what I see happening in the tech space, I think that trend is going to continue: love it or hate it, the future is most likely going to be Rust encroaching on C, with C increasinly being relegated to the "legacy" status like COBOL and Fortran. In the words of Ambassador Kosh: "The avalanche has already started. It is too late for the pebbles to vote."

0: https://blog.regehr.org/archives/1180 1: https://blog.regehr.org/archives/1287

[Macha]

I think the problem with "friendly C", "safe C++" proposals is they come from a place of "I want to continue using what I know in C/C++ but get some of the safety benefits. I'm willing to trade some of the safety benefits for familiarity". The problem is the friendly C/safe C++ that people picture from that is on a spectrum. On one end you have people that really just want to keep writing C++98 or C99 and see this as basically a way to keep the network effects of C/C++ by having other people write C who wouldn't. The other extreme are people who are willingly to significantly rework their codebases to this hypothetical safe C.

The people on one end of this spectrum actually wouldn't accept any of the changes to meaningfully move the needle, while the people on the other end have already moved or are moving to Rust.

Then in the middle you have a large group of people but not one that agrees on which points of compatibility they will give up for which points of safety. If someone just said "Ok, here's the standard variant, deal with it", they might adopt it... but they wouldn't be the ones invested enough to make it and the people who would make it have already moved to other languages.

[musicale]

Apologies for mentioning the same idea in multiple comments, but it seems relevant.

In my opinion, a good path forward is to add safety features to mainline C toolchains. An example is -fbounds-safety for clang/llvm

https://clang.llvm.org/docs/BoundsSafetyAdoptionGuide.html

[pjmlp]

History has already proven this with Objective-C and C++, also with TypeScript, while those languages provide stronger safety guarantees over plain old C and JavaScript, there are always those that will keep using the old tricks on the new system.

Only removing copy-paste compatibility fixes that.

[awesome_dude]

> Luckily there’s an easy away forward, which is to skip the step where we try to get consensus.

This is true, the Benovolant Dictator model, versus the Rule by committee model problesm.

Committees are notorius for having problems coming to a consensus, because everyone wants to pull in a different direction, often at odds with everyone else.

Benevolent dictators get things done, but it's not necessarily what people want.

And, we live in hope that they stay benevolent.

[musicale]

The path forward I see is improved safety features for popular C compilers and toolchains.

Ultimately it may be necessary to convince standards committees, but it seems like adding features and flags into mainline clang/llvm (and/or gcc, visual studio, ...) paves the road toward improved memory safety for C at large.

For example, if clang supported it out of the box, I could imagine OpenBSD (or macOS or other OSes that use clang) eventually compiling all (or nearly all) of its C code, including kernel, library, and userland code, in safe mode - and maybe even making it the default. In fact we already see certain safety flags and compiler/runtime features being adopted.