C++ Committee Prioritizes 'Profiles' Over Rust-Style Safety Model Proposal

Long-time Slashdot reader robinsrowe shared this report from the Register: The C++ standards committee abandoned a detailed proposal to create a rigorously safe subset of the language, according to the proposal's co-author, despite continuing anxiety about memory safety. "The Safety and Security working group voted to prioritize Profiles over Safe C++. Ask the Profiles people for an update. Safe C++ is not being continued," Sean Baxter, author of the cutting-edge Circle C++ compiler, commented in June this year. The topic came up as developers like Simone Bellavia noted the anniversary of the proposal and discovered a decision had been made on Safe C++.

One year ago, Baxter told The Reg that the project would enable C++ developers to get the memory safety of Rust, but without having to learn a new language. "Safe C++ prevents users from writing unsound code," he said. "This includes compile-time intelligence like borrow checking to prevent use-after-free bugs and initialization analysis for type safety." Safe C++ would enable incremental migration of code, since it only applies to code in the safe context. Existing unsafe code would run as before.

Even the matter of whether the proposal has been abandoned is not clear-cut. Erich Keane, C++ committee member and co-chair of the C++ Evolution Working Group (EWG), said that Baxter's proposal "got a vote of encouragement where roughly 1/2 (20/45) of the people encouraged Sean's paper, and 30/45 encouraged work on profiles (with 6 neutral)... Sean is completely welcome to continue the effort, and many in the committee would love to see him make further effort on standardizing it."

In response, Baxter said: "The Rust safety model is unpopular with the committee. Further work on my end won't change that. Profiles won the argument." He added that the language evolution principles adopted by the EWG include the statement that "we should avoid requiring a safe or pure function annotation that has the semantics that a safe or pure function can only call other safe or pure functions." This, he said, is an "irreconcilable design disagreement...."

There is already a safe subset of C++

[EMB Numbers]

There is already a safe subset of C++ as demonstrated by safety critical code including code in aircraft cockpits. Standards like Motor Industry Software Reliability Association (MISRA) exist for C++. Such standards generally include rules prohibiting dynamic resource allocation at run time. All threads and all memory must be allocated are compile time or at initialization time. Of course, following these rules means that 90% of the Standard Template Library (STL) cannot be used. All memory accesses must be bounds checked, etc.

I live in the world of MISRA C++. It is surprisingly easy to live with the constraints. I work in large code bases that do not contain a single "new" or "delete". The problem is that most programmers are unaware of the risks that standards like MISRA try to mitigate. Programmers are poorly trained about memory safety and dynamic resource allocation. In my opinion, languages like Rust exist to put ignorant programmers in straight jackets for their own good. Java tried to do the same thing with "managed" code. The real solution is to cultivate less ignorant programming programmers.

With all of the above said, there are two different worlds of programming: Closed World, and Open World. This is not a reference to Opensource. This is about he types of problems to be solved.

Closed world is like ethe transmission in a traditional car. All of the parts are created to exacting standards and fit together only one way. Transmissions are not user serviceable. Any modifications to the transmission likely degrade its functionality. All of the parts were present at the factory (compile time), and none will ever be added or removed (no dynamic resource allocation).

Open World problems are like the trunk of the car. Nobody at the factory can predict everything that might be stored in the trunk. Items are added and removed from the trunk all the time. Limitations to the contents of the trunk make the trunk less useful. Databases and authoring tools like Word or Blender and most user interfaces with plugins etc. are exist in the Open World. Limitations to the number of pages in your document or the number of tables in your database make the documents and databases less useful.

C++ is used to solve both Closed World and Open World problems. C++ id the largest most complex programming language ever conceived in part because it tries to be everything for everyone. This is why "Profiles" are so important. If I understand correctly, "Profiles" identify subsets of teh languages and force programmers to live within the selected subset. In reality, this is the only way C++ programmers survive today. Everybody chooses a subset of the language. Unfortunately, even team chooses a different subset, so when components are integrated from multiple teams/suppliers, the union of the subsets produces a larger subset. Since and repeat until you are using the entire language again.

By the way, tools exist to audit C++ code for things like MISRA compliance. Adding such tools to the language itself may not be particularly valuable...

Re:

[nadass]

This comparative metaphor makes sense. But it seems the C++ EWG is hoping to contain bad code (put limits on the trunk's abilities) rather than creating a culture of good code (teaching drivers efficient usage of the trunk).

In the end, EWG doesn't want to nurture a culture of safe code; they want safe code to happen by accident. Wishful thinking indeed...

Re:There is already a safe subset of C++

[Waffle Iron]

languages like Rust exist to put ignorant programmers in straight jackets for their own good

Are you seriously trying to suggest that never allocating memory is not also a "straight jacket"?

You seem to be saying that a currently existing bowdlerized version C++ is safe for close-world problems. Possibly so, but that still leaves C++ unsuitable for open-world problems. That makes C++ only suitable for niche applications. Why learn it?

If you just use Rust or any other memory safe language, you won't have to worry about what kind of "world" you're writing for, or about choosing from a range of increasingly dangerous "profiles".

Re:

[Pinky's Brain]

That is no longer a system programming language.

Re:There is already a safe subset of C++

[sinij]

The real solution is to cultivate less ignorant programming programmers.

No, this is utopian solution. The real solution is to have programming tools that can allow average programmer to produce safe compiled code.

By your logic, we don't need seat belts in cars

[Somervillain]

Programmers are poorly trained about memory safety and dynamic resource allocation. In my opinion, languages like Rust exist to put ignorant programmers in straight jackets for their own good. Java tried to do the same thing with "managed" code. The real solution is to cultivate less ignorant programming programmers.

The problem with your comment is that the most destructive exploits were introduced by well trained programmers who knew what they're doing. And with security, you can do a billion things right and one stupid mistake from someone else and your system is hacked. This is akin to seat belts. I've never needed one. I've just taken the strategy of never being in an accident for the 30 years I've been driving. However, I am not stupid enough to think I don't need a seat belt. Even if I never make a mistake,

Re:

[jd]

Ish.

I would not trust C++ for safety-critical work as MISRA can only limit features, it can't add support for contracts.

There have been other dialects of C++ - Aspect-Oriented C++ and Feature-Oriented C++ being the two that I monitored closely. You can't really do either by using subsetting, regardless of mechanism.

IMHO, it might be easier to reverse the problem. Instead of having specific subsets for specific tasks, where you drill down to the subset you want, have specific subsets for specific mechanisms

Re:

[John Allsup]

If you put programmers inside the Rust straitjacket until they understand the nature of it and the reasoning behind it, and then let them use C++, they'll probably be conditioned to be memory safe. Rust forces you to do what you should be doing anyway in a language like C++. And Rust can compile-time check that stuff.

I'm very much a 'do the experiment' person when it comes to C++ vs Rust. There is plenty of will to write stuff in Rust, so the rest of us can grab popcorn, watch, and then observe the outcomes

It was good but not great.

[Gravis Zero]

Before everyone gets their panties in a wad, while the Rust-style draft claims it "can’t break existing code", existing code also can't use it without breaking. Effectively, only code seeking to be safe would be use the features and I think that's what the C++ committee didn't like. It means all old code would have be revised which would result in a huge amount of code debt.

The "Profiles" approach seems more directed toward compilers finding existing issues in codebases which means all code will benefit and can quickly be fixed. There is far less code debt in this approach and the severity could be an reduced to compile-time warnings which makes migration much easier.

Re:

[nadass]

This implies the different approaches are like building a house with a safe and solid foundation, or patchworking a foundation with copious amounts of duct tape.

And in this vein, the C++ EWG prefers the duct tape approach... because laying new foundations in a well-regulated manner is hard, or rather, presents an "irreconcilable design disagreement...."

Taking a step back, the EWG (like all corporate programmers) are taking the path of least resistance ("what checks the box yet requires the least amoun

Hold up, friend.

[Gravis Zero]

You should look at the Rust-style draft because you have to manually enable it for every part of code that you want to be safe. You can totally ignore and just not use it. It's not the "solid foundation" you seem to think it is.

Zzzz

[fluffernutter]

Wake me up when Qt is memory safe.

Huh?

[Gravis Zero]

Qt's memory management is entirely based on using shared pointers. Honestly, it's kinda hard to screw up with Qt, like you have to go out of your way to screw up. i mean, other than failing to specify a parent object, how are you having memory issues in Qt?

Re: Huh?

[t_hunger]

I have hunted my fair share of core dumps in Qt code. Each one is a memory safety fail... it is, just like the rest of C++ not memory safe.

I find it funny that so many C++ devs seem to think using smart pointers means you are memory safe. It does not, there is so much more needed... check what the "safe C++" proposal set out to change, that's what you need tomdo to make C++ memory safe using the approach rust took. It includes fun stuff like new reference semantics, destructive moves and a new standard libr

Re:

[Gravis Zero]

Each one is a memory safety fail... it is, just like the rest of C++ not memory safe.

Like I said, you have to go out of your way to screw up. I never claimed it was perfect, only that you have to do something particularly dumb to break it. There is always going to be idiots in the ER because they used a tool the wrong way.

I find it funny that so many C++ devs seem to think using smart pointers means you are memory safe.

Safer, yes. Perfectly safe, no. When you build a fool-proof system then someone will build a better fool.

check what the "safe C++" proposal set out to change

I did. I even explained why it wasn't chosen. [slashdot.org] It's no panacea and as someone else pointed out [slashdot.org], safe subsets of C++ exist.

Re:

[fluffernutter]

You are referring to knowing the difference between shared pointers and unique pointers. That's the only way to screw it up. Yes, if you confuse a unique pointer for a shared pointer you screw it up. But if you don't know that one fact then you have no business coding C++ at all, especially since it is usually just a matter of sticking to using shared pointers all the time.

Re: Keep rust in rust

[t_hunger]

There is increasing pressure on companies to take responsibility for their software products. This includes preasure to move towards memory safe languages. This exercise is about getting C++ of the governments naughty lists, so that people can continue to use C++ without extra regulatory overhead and too much risk to the company.

Rust is just a working example of a language with similar performance to C++, whise approach could be copied. The committee opted to not do that and go for something that does not m

Do it yourself

[allo]

You don't need the language to enforce memory safety to program memory-safe. The most important thing is, for example, to never touch raw pointers. C++ makes it very easy to avoid this. Rust forces you to avoid it, but just because C++ gives you the loaded gun, it doesn't mean you have to use it. In particular not on your own foot.

Re:

[HiThere]

You oversimplify. I despise Rust, but it does address real problems. (I'm not sure how well, because I won't use it.) I'm thinking of thinks like deadlock, livelock, etc. As someone above pointed out, there are lots of applications that don't need to deal with that, and subsets can work for them. (The above poster worked in a domain where all memory could be pre-allocated.)

Rust felt like programming with one hand tied behind my back. So I dropped it. Only one reference to a given item it just too res

Re:

[SoftwareArtist]

I don't know of a better language than Rust for the specific case it's designed for: performance critical code. It's for when you want your code to run as fast as it possibly can, and you're willing to work harder for it. I don't know of any other language that can do that without sacrificing memory safety.

If you don't mind sacrificing a little speed, lots of languages provide memory safety with a lot less work. For most projects, that's the right choice. When you care about every last bit of speed, tho

Re:Do it yourself

[Waffle Iron]

You don't need the language to enforce memory safety to program memory-safe. The most important thing is, for example, to never touch raw pointers. C++ makes it very easy to avoid this. Rust forces you to avoid it, but just because C++ gives you the loaded gun, it doesn't mean you have to use it. In particular not on your own foot.

That is a dangerous misconception. You don't need to use any pointers to get memory errors in C++:

#include <stdio.h>
#include <vector>
 
int main() {
    std::vector<int> v = {1, 2, 3, 4, 5, 6, 7, 8, 9};
    for (auto i : v) {
        if (i % 2 == 0) {
            v.push_back(i + 10);
        }
        printf("%d\n", i);
    }
 
    return 0;
}
 
$ g++ -Wall -pedantic t.cpp
$ echo $?
0
$ ./a.out
 
1
2
-947527061
1600570778
5
6
7
8
9

Re:

[EMB Numbers]

Nobody said the Standard Template Library (STL) wasn't a monstrosity :). The "rules" of mutable collections in STL state that collections may not be mutated while being iterated.

Note: The free Cppcheck that should be part of every C++ build system states:

~/Desktop/bug/bug/build $ cppcheck ../main.cpp
Checking ../main.cpp ... ../main.cpp:8:15: error: Calling 'push_back' while iterating the container is invalid. [invalidContainerLoop]

Re:

[Waffle Iron]

The "rules" of mutable collections in STL state that collections may not be mutated while being iterated.

Nope. If I had used st::list instead of std::vector, it would have been perfectly fine and officially supported. (Assuming I changed "i+10" to "i+11" in order to make the algorithm actually terminate, although that change wouldn't affect the vector crash.).

The problem is that there are dozens of different rules you have to remember to apply to the different types of lists and iterators. And that's only talking about that one topic. There are hundreds of other rules covering a multitude of language aspects t

Re:

[EMB Numbers]

So don't use STL and do use clang-tidy and Cppcheck and flaw finder and Sonarqube. All but the last are free. Cppcheck apparently knows "hundreds of other rules covering a multitude of language aspects" so you don't "have to mentally apply against every single line of code you write."

Re:

[Waffle Iron]

So don't use STL

Indeed, No True Scotsman would use STL with C++.

clang-tidy and Cppcheck and flaw finder and Sonarqube

The last job I had where I had to use C/C++, we automatically ran an expensive static analysis tool every time we checked in code. I'd estimate that it only found about half of the potential segfaults, and it made up for that by finding twice as many false positives.

Re:

[bsolar]

The "rules" of mutable collections in STL state that collections may not be mutated while being iterated.

That's pretty common knowledge for an experienced programmer, but still something the programmer needs to know in a language like C++ to avoid writing unsafe code. Even using a static analysis tool is something the developer need to know and actively pursue.

The contrast is with languages that attempt to prevent even the unwary from writing unsafe code.

time to move on from C++ Std committee

[cleanmachine]

I fear that the C++ standards committee structure is not up to this task despite all the talent there. A major compiler project or vendor probably just needs to implement their solution and see if they can actually solve the problem.
I think it could succeed even without committee blessing because it is such an crucial need: need to avoid re-writing all our working C++ code, but we need to be able to incrementally add to it or modified part of making it progressively more safe.

If a implementation arrives th