C++ Safety, in Context

https://herbsutter.com/2024/03/11/safety-in-context/

by ingve • 2 years ago

145 362 2 years ago

I saddens me that smart people like Herb and Bjarne have good ideas on how to make C++ a much safer language but the actual output of the standard's committee is so far behind.

Herb mentions std::span as as safety improvement but the [] operator doesn't do bounds checks and the .at() method isn't even there yet!

Shameless plug but I discuss this issue on my blog: https://btmc.substack.com/p/memory-unsafety-is-an-attitude-p...

Herb and Bjarne have the right attitude, sadly it doesn't seem enough C++ devs or people in the standards committee do. Same applies to C.

pjmlp16• 2 years ago

Here is Dennis Ritchie proposal for fat pointers in C.

https://www.bell-labs.com/usr/dmr/www/vararray.pdf

It is a culture thing, eventually the authors don't have any last words to say, if they let the community rule the language design, and their voice is equally one vote.

sirwhinesalot12• 2 years ago

This is a version of a paper published in Journal of C Language Translation, vol 2 number 2, September 1990

This says it all really. Nothing more needs to be said. Unfortunate.

GrumpySloth2• 2 years ago

At $work, the standard solution to ASAN reporting use-after-free issues is to... not run ASAN builds. The fact that builds in CI exhibit random inexplicable crashes regularly every week doesn’t seem to make anyone have any second thoughts. A colleague once claimed that there is nothing wrong with out-of-bounds accesses as long as we don’t crash. The same bunch is also religiously opposed to using debuggers and regularly break debugger builds by removing debug information from builds at multiple levels, blocking ptrace debugging in system images through sysctl... This is all so toxic.

sirwhinesalot12• 2 years ago

My personal opinion is that if companies would get real punishments for all of these goddamn security breaches, and the CTO's head was on the line, you'd see a shift in attitude real quick.

dmm• 2 years ago

A colleague once claimed that there is nothing wrong with out-of-bounds accesses as long as we don’t crash.

I need to find the source, but someone pointed out that the safety advantages of Rust are, in part, cultural and I increasingly agree. People use Rust because they care about memory safety and that care is reflected in the programs they write.

gpderetta9• 2 years ago

Even if not mandated by the standard, concrete standard library implementations do provide bound checking on span (and vector, and optional, etc.), but, even when meant for production use, are disabled by default.

And I don't see a big push in the community to enable them. I think the committee is just an expression of the community on this front.

account42• 2 years ago

Even if not mandated by the standard, concrete standard library implementations do provide bound checking on span (and vector, and optional, etc.), but, even when meant for production use, are disabled by default.

That's a choice though. You can enable these in your production builds if you want (with libstdc++ at least) and some Linux distributions have chosen to do just that.

The thing though is that these checks are NOT free and the overhead is not justified for all use cases so forcing them on everyone is not appropriate for C++.

jasode2• 2 years ago

but the actual output of the standard's committee is so far behind.

That criticism misunderstands the actual way the C++ committee works. They're not a supreme legislative group that can dictate what a new C++ should be and everybody else is required to just obey. In contrast, Apple can dictate what the next version Swift will do. Microsoft can do the same with C#.

Instead, what happens in C++ is somebody or company makes a proposal with some concrete working code for others to evaluate and vote "yes" on. So the reality means one of the teams from MSVC, gcc, clang, Intel C++, etc have to take the lead with a Safe C++ alternative that convinces everybody else to implement.

To Herb Sutter's credit, he did make a "C++2" implementation: https://github.com/hsutter/cppfront

But his side project at Microsoft didn't gain traction with gcc, clang, etc and everybody else in the industry. So at this point, the C++ committee will be perceived as "so far behind" ... because there's nothing for them to vote on.

Similar situation happened with "breaking ABI compatibility". Google wants to break ABI but others didn't.

pjmlp16• 2 years ago

And that is why while C++26 is being discussed, C++20 modules are still full of warts, working on Visual C++ (kind of), and not really anywhere else, as ISO C++ has long stop being about standardizing stuff with actual field experience.

paulddraper8• 2 years ago

Not a C+++?

humanrebar8• 2 years ago

...the actual output of the standard's committee is so far behind

The committee just publishes documents. It is actually far ahead of C++ implementations.

The committee would probably move faster if there were more attention (and funds and volunteer work) spent on advancing C++ implementations. This especially seems true for safety and security concerns as they tend to have more tangible problems to solve than the other kinds of standards proposals.

sirwhinesalot12• 2 years ago

You're not far ahead if you're running in the wrong direction.

The standard is prioritizing the wrong things. It's normal that implementations are struggling when they need to implement something as complicated as C++ modules for example. There's no excuse for the .at() method being missing from std::span.

On the C side of things the problem is more egregious, it took over 30 years to standardize typeof after every compiler ever had already implemented something of the sort. GCC's __attribute__((cleanup)) should have definitely been standardized ages ago with so many libraries and codebases relying on it.

What does the C standard give us instead? _Generic. It's just silly at this point.

stefanos82• 2 years ago

Herb mentions std::span as as safety improvement but the [] operator doesn't do bounds checks and the .at() method isn't even there yet!

You mean this implementation? https://en.cppreference.com/w/cpp/container/span/at

To quote: "Returns a reference to the element at specified location pos, with bounds checking.

If pos is not within the range of the span, an exception of type std::out_of_range is thrown."

pjmlp16• 2 years ago

You missed the Std column => (C++26)

AlbertoGP2• 2 years ago

Shameless plug but I discuss this issue on my blog:
“First make them care, then make it easy for them to do the right thing.”

I would say first make it easy to do the right thing, making them care will be an Eternal September.

sirwhinesalot12• 2 years ago

Sadly even if you make it easy to do the right thing, without the right attitude to match it matters little. Some people still concatenate unsanitized input with raw SQL strings despite the abundance of libraries that make creating safe queries easier.

At this point I think heads need to roll before people take the problem seriously.

pptr7• 2 years ago

Being able to use a foreach loops is a decent improvement.

And since you now have a proper access API, you could on theory enable bounds checks via compiler flag, even for operator[].

nindalf22• 2 years ago

All languages have CVEs, C++ just has more (and C still more); so far in 2024, Rust has 6 CVEs [1], and C and C++ combined have 61 CVEs [2]. So zero isn’t the goal; something like a 90% reduction is necessary, and a 98% reduction is sufficient, to achieve security parity with the levels of language safety provided by MSLs

The author is making a massive assumption that all CVEs are equally serious but they aren't. Opening the Rust links indicates several of them are denial of service, including regular expression denial of service. Not downplaying this, but compare it to the first result in the other link, which involves potential remote code execution (RCE).

Take for example CVE-2022-21658 (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) in Rust, related to a filesystem API. It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed. That's why counting CVEs alone is meaningless.

The author concedes that CVEs are not a good metric to measure by, but implies that maybe C and C++ have too many CVEs that shouldn't actually be CVEs and that the C++ community should take more control of CVEs being filed. This is ominous, and makes me fear we might start to see fewer C and C++ CVEs because issues will be closed as "intended behaviour" or "won't fix", like the filesystem issue above.

[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

[2] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=c++

criddell• 2 years ago

His 98% figure sounds about right, doesn’t it? Eliminate 98% of C++ CVEs and that’s enough to compete with memory safe languages.

nindalf22• 2 years ago

Except the CVEs in Rust are far more likely to be low severity issues that C++ would never acknowledge to begin with.

lifthrasiir4• 2 years ago

Sounds about right because he is using the number of eliminated CVEs, not the number of remaining CVEs. Compare with 98% and 99.8%; even when we have been tracking all possible CVEs, 98% elimination will leave 10x remaining CVEs than 99.8% elimination. (Of course both are much better than 0% elimination, i.e. status quo.) I feel the true figure would be somewhere around 99.8% and 99.98%, especially when a massive undercount from existing C/C++ projects is accounted for.

saagarjha5• 2 years ago

Absolutely not. Software that has 98% fewer memory safety issues is…still exploited. People just look harder and the costs go up a bit.

saghm10• 2 years ago

Is aiming for exact parity the best way to achieve that though? I'm skeptical that memory safe languages have 98% fewer CVES than C++ because their goal wass "have 2% of the CVEs that C++ has" and they succeeded and not "try to have no CVEs whatsoever" and they failed by a small amount.

pizlonator15• 2 years ago

But how do you know that the language has eliminated 98% of vulnerabilities?

98% of what? CVEs? Something else?

pjdesno• 2 years ago

The most recent data I could find, from 2019, shows that 17% of CVEs are in PHP code, 12% in Java, and 11% in JavaScript - all memory-safe languages.

Memory safety bugs are only one class of security vulnerabilities, and there's nothing magical about memory safeness that causes a developer using that language to suddenly become expert at writing secure code.

For that matter, some vulnerabilities actually seem much more common in memory-safe languages - try searching the CVE database for "SQL injection c++" (287 results) vs javascript (3420), Java (2160), or PHP (11300).

humanrebar8• 2 years ago

Or you can flip it around and ask why there isn't a body in the C and C++ community funding tangible advancements in the security and safety problem space the way the Python Foundation and Rust Foundation are.

nindalf22• 2 years ago

I don't know about this. There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams. The author of the post we're discussing is a member of the committee and this article is an attempt to improve the security situation in C++.

So funding isn't the issue. The issue is that the committee has a firm commitment to never introducing breaking changes. This commitment is so firm that it trumps literally any other interest, like making the language memory safe. That's why the author only suggests non-breaking changes in this article.

Lots of people are going to have opinions on whether this approach is the right one for C++'s long term success, but I think we'll only know in 5-10 years.

adev_7• 2 years ago

Take for example CVE-2022-21658 (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) in Rust, related to a filesystem API. It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all.

That just plain wrong. Just simply wrong. And I hope it is not a lie done on purpose.

The C++ community acknowledge the issue as soon as the Rust one posted the problem and issued a fix which is already deployed with major compilers [^1] [^2]

It does not have a CVE associated since the issue was spotted within Rust stdlib first.

This is this exact kind of FUD and zealotism that makes people hate the Rust community. I wish the community mature a bit on this aspect.

[^1]: https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d...

[^2]: https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9...

nindalf22• 2 years ago

It does not have a CVE associated since the issue was spotted within Rust stdlib first.

I don't see why this is true. Are you saying that people with affected code would have seen a Rust CVE and then updated their C++ toolchains? There seems to be no reason this shouldn't have been a C++ CVE other than the fact that C++ community has different standards for what constitutes safety. The lack of CVE associated with the fixes you pointed out support the original assertion rather than refuting it.

In fact, I'll tell you why there was no CVE for C++ - concurrent access to filesystem APIs is undefined behaviour in C++ (https://en.cppreference.com/w/cpp/filesystem).

Reasonable people can disagree on this though, so I can see where you're coming from. There's no reason to immediately fling around accusations of lying and zealotry. It makes the writer look immature.

masklinn• 2 years ago

It does not have a CVE associated since the issue was spotted within Rust stdlib first.

That is blatant nonsense. Even if the vulnerability is similar or identical, CVEs are submitted for every affected project. If it were not there would not have been a bounds-check CVE in the last 35 years. The only situation in which that might not be the case is if the vulnerability is in an upstream library, but even then you often get a CVE in both upstream and downstream (or a CVE shared between multiple products) e.g. the libwebp 0-day from late 2023 got a CVE for Apple’s various OS (two in fact) and a shared CVE for libwebp and chrome, mozilla used that as their upstream CVE in emitting a security advisory.

The CVE-2022-21658 only covers the Rust standard library, that is not upstream of either libc++ or libstdc++, and neither fix references it anyway.

The GP might have gone a hair too far in saying that C++ “does not consider it a problem at all”, but they’re correct that C++ compiler/stdlib maintainers do not consider it a vulnerability.

CJefferson4• 2 years ago

I was pointed multiple times by people to the C++ standard, which clearly states (when introducing the filesystem library):

"The behavior is undefined if the calls to functions in this library introduce a file system race, that is, when multiple threads, processes, or computers interleave access and modification to the same object in a file system."

and was told that made this bug not a compiler issues, but just undefined behaviour, exactly as if you'd written an array out of bounds or dereferenced an invalid pointer, the compiler can do anything it likes if another program changes the filesystem while your program runs.

pornel• 2 years ago

The CVE/CVSS system lacks ability to deal with soundness issues.

If the language or a library promises to catch a mistake, and it doesn’t, that’s not automatically exploitable unless the programmer has actually made that mistake. If there wasn’t a promise in the first place, there would be nothing to report.

Unfortunately, CVE can’t see the difference between reporting a bug, or reporting a theoretical possibility of having a bug that never actually happened.

mattgreenrocks• 2 years ago

Frankly, I don't think industry is going to allow soundness issues to ever achieve parity of importance with what we think of as CVEs. There's simply too much code and mindshare around languages that don't worry as much about soundness.

I'm not saying it is right, just that concerns around soundness will likely be hand-waved away. And it is to everyone's detriment.

saghm10• 2 years ago

Not to mention the weird conclusion that since no language has 0, that isn't the goal. I'm not sure I understand the logic that you shouldn't at least _try_ to not have any major security flaws. My interpretation of the CVE counts he mentions is that if your goal is zero, you might end up still having a few, but if your goal is just "few enough that people stop complaining about us being worse than other languages in a similar niche", you probably will end up not hitting that threshold either, which seems like a plausible explanation for how C++ is in this situation in the first place. The fact that he brings up C a bunch also seems like it could be related to this; it sort of feels like he's focusing too much on the idea of security as a competition between languages rather than something that's inherently worthwhile as a goal in its own right.

kllrnohj16• 2 years ago

The point is that trying to hit 0 would be a huge breakage that would fragment the language, and there's no actual evidence to suggest such a thing is actually necessary.

It's like your front door's lock. It doesn't have to be unpickable, unshimmable, absolutely secure. It just has to put up more of a fight than a brick through the window.

pizlonator15• 2 years ago

Yeah.

What I like about the 100% memory safe goal is that it’s a falsifiable goal.

Even the Rust style goal of “you’re memory safe if you do 100% rust and never use unsafe” has the nice property of being falsifiable.

98% memory safe is not a falsifiable goal. It gives the C++ designers the option of never actually fixing the problem while claiming they had by picking a sloppy way of measuring the “%”.

PH95VuimJjqBqy14• 2 years ago

Not to mention the weird conclusion that since no language has 0, that isn't the goal. I'm not sure I understand the logic that you shouldn't at least _try_ to not have any major security flaws.

He addressed that, the cost of making it to 0 would be too great (C++ would have to break backwards compatibility) so we should try and be inline with other languages instead.

I don't understand why you're acting as if he didn't make the point he made.

kllrnohj16• 2 years ago

It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed.

Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all.

Case in point, this was fixed in both major C++ libraries:

https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d...

https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9...

So what C++ community refused to regard this as an issue and refused to fix it? Where is your supporting evidence for your claims?

nindalf22• 2 years ago

I stand corrected that the issue wasn't fixed (https://news.ycombinator.com/item?id=39680006). The issue was fixed, but no CVE by the C++ libraries. That reinforces the point that the author's attempt to equate 1 Rust CVE = 1 C++ CVE isn't valid.

kouteiheika• 2 years ago

Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all.

Relevant piece of the standard: http://eel.is/c++draft/fs.race.behavior#1.sentence-2

Officially it's undefined behavior.

And here's a comment from the maintainer of the STL in MSVC regarding this: https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_cultu...

Kranar8• 2 years ago

Saying it was fixed in two of the three C++ standard libraries is irrelevant, the language standard itself specifies that the behavior is undefined.

This would be like saying C++ the language fixed buffer overflows because GCC added bounds checking. Most sensible C++ developers know that you should not depend on undefined behavior to write correct software, and yet your argument that because some implementations (not all) have decided to provide semantics for this, that it's now okay to use it or no longer a problem.

cozzyd2• 2 years ago

What if you normalize for the amount of code in the wild? Relatively little software I use day to day have significant amounts of rust in them (only Firefox and my phone OS, probably...). Even in firefox, there is far more C++ than rust...

steveklabnik10• 2 years ago

You’d also have to define what “use” means. Your traffic that goes through Cloudflare hits Rust code: does that count as a “use”? Sites you use that rely on AWS almost certainly hits Rust code, does that count as a “use”?

I think it’s kind of stretching it, but these are services where issues in them could impact you, so I don’t think it’s a total non sequitur.

CJefferson4• 2 years ago

Comparing CVEs is unfair, in the past there have been CVEs in the Rust for things which in C++ were just marked “won’t fix” (this one: https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html )

kllrnohj16• 2 years ago

Links to where C++ marked it "won't fix" please (hint: you won't find them, both libc++ and libcxx treated them with severity & promptness and resolved the issue quickly)

dralley2• 2 years ago

But still, there was no CVE filed, so comparing Rust to C++ on that front is apples-to-oranges. Rust has a lower bar for what can be considered a serious flaw.

burntsushi5• 2 years ago

Sutter correctly points out that when using pointers in safe Rust, one is generally limited to tree structures. But, that one can express cyclic structures in safe code using other means (such as reference counting or integer indices):

One reason is that Rust’s safe language pointers are limited to expressing tree-shaped data structures that have no cycles; that unique ownership is essential to having great language-enforced aliasing guarantees, but it also requires programmers to use ‘something else’ for anything more complex than a tree (e.g., using Rc, or using integer indexes as ersatz pointers); it’s not just about linked lists but those are a simple well-known illustrative example.

But then later on, seems to ignore the safe alternatives and commits a non-sequitur:

That’s because a language’s choice of safety guarantees is a tradeoff: For example, in Rust, safe code uses tree-based dynamic data structures only. This feature lets Rust deliver stronger thread safety guarantees than other safe languages, because it can more easily reason about and control aliasing. However, this same feature also requires Rust programs to use unsafe code more often to represent common data structures that do not require unsafe code to represent in other MSLs such as C# or Java, and so 30% to 50% of Rust crates use unsafe code, compared for example to 25% of Java libraries.

In other words, Sutter acknowledges the safe alternatives at one point, but then ignores them later. When ignoring them, it allows Sutter to draw a conclusion as to why some percentage of Rust code uses `unsafe`. And even if ignoring those alternatives was appropriate here, I still see no reason to believe that 30%-50% of Rust crates use `unsafe` precisely because of the limitations around cyclic structures. There are many more reasons to use `unsafe`.

[1] https://thenewstack.io/unsafe-rust-in-the-wild/

galangalalgol2• 2 years ago

I would have guessed most uses of unsafe dealt with c abi bindings. People do like to create interesting data structures in rust, but I don't see any of that in my cargo tree, and I suspect most people don't.

soulbadguy8• 2 years ago

But then later on, seems to ignore the safe alternatives and commits a non-sequitur

I think it's possible to read the argument in the way that make sense.

I don't think that Hurb is making the point here that Rust code uses more unsafe code pacifically "because" the the tree-base dynamic data structures restrictions. It seems that he took this simply as an illustration of a larger point.

The point he is making is that programming language safety is always a trade-off. Rust and Java are making different trade-offs which results in a different level/kind of safety.

We should also note, even if there are "safe" alternatives in rust, it doesn't mean those alternative are viable in term of code complexity, performance, cache behavior etc... etc... So the existence of safe alternative doesn't negate the need to use unsafe if one doesn't like the trade-off those safe alternatives imply.

I don't think it's a particularly big problem that more part of rust are unsafe vs Java, and probably reflect rust focused on native performance more than anything else.

But for the purpose the Hurb conversation here, this fact is important to note.

burntsushi5• 2 years ago

It's definitely a trade off. But Sutter is extremely selective in the analysis put forward on that trade off. Selective enough that I find the wording pretty misleading overall. And that particular paragraph is still a non-sequitur. The language used is pretty clearly "because foo, bar happened." Emphasis mine:

However, this same feature also requires Rust programs to use unsafe code more often to represent common data structures that do not require unsafe code to represent in other MSLs such as C# or Java, and so 30% to 50% of Rust crates use unsafe code, compared for example to 25% of Java libraries.

This isn't a carefully considered statement about trade offs. This is sloppy reasoning. For example, if the reality were that 99% of that `unsafe` code were just FFI interactions with programming languages that are memory unsafe by default, then that would kind of undercut the entire point here. That is, it wouldn't really be Rust's fault. It would be the fact that we've lived in a memory unsafe hegemony in systems languages for the last several decades. That's just reality.

Of course, I'm sure it isn't 99%. But I'm also sure it isn't 1% either. The reality is so much more interesting than "30%-50% of all crates have `unsafe` in them." And that reality could very well undercut the entire point Sutter is making in this part of the article.

Diggsey• 2 years ago

30% to 50% of Rust crates use unsafe code

This is particularly misleading for two reasons:

1) There are a lot of `-sys` crates which link to C libraries, so the "unsafe" code in these crates comes from the binding to C rather than some limitation of Rust. Often there are 100% safe Rust alternatives to these C libraries as well.

2) Of the remaining crates which use "unsafe", the unsafe code is often contained to a tiny percentage of the code, so if we're looking at the overall amount of unsafe code, you're going from 100%, to a fraction of a percent.

soulbadguy8• 2 years ago

1) There are a lot of `-sys` crates which link to C libraries, so the "unsafe" code in these crates comes from the binding to C rather than some limitation of Rust. Often there are 100% safe Rust alternatives to these C libraries as well.

Sure... but it's still unsafe code ... with the the consequences of unsafe code. Also doesn't also explain the 30 % to 50 % vs 25 % in Java. My guess would be that java just care less about perf. I mean if blaming a language "unsafeness" on C is an options, i submit that a lot of the unsafe part of C++ where imported wholesale from C.

2) Of the remaining crates which use "unsafe", the unsafe code is often contained to a tiny percentage of the code, so if we're looking at the overall amount of unsafe code, you're going from 100%, to a fraction of a percent.

Three points :

First, code volume is a good proxy only when the code samples are uniformly distributed : while the unsafe code might be a tiny percentage of the code base, they might represent a large percentage of runtime and/or a large part of the algorithmic complexity of the whole project.

Second going from 100 % to tiny fraction implies that C++ is 100% percent unsafe... and that's not the case. There is safe subset somewhere deep in there.

And third, "unsafe rust" is not safer than "regular C++" . Mixing those 3 factor makes the finally "safety" tabulation much more complicated than just counting number of unsafe regions

paulddraper8• 2 years ago

Correct.

By any fair measure, unsafe Rust is a tiny fraction of total Rust code.

In my experience, the community eschews it with a fervor bordering on religiosity.

PH95VuimJjqBqy14• 2 years ago

Of the remaining crates which use "unsafe", the unsafe code is often contained to a tiny percentage of the code, so if we're looking at the overall amount of unsafe code, you're going from 100%, to a fraction of a percent.

I dislike this argument because rust unsafe code is typically placed into a module with safe code around it protecting it.

Guess how good C++ code is written?

exactly. The unsafe keyword certainly helps but is not a panacea nor a guarantee given that a bug in the safe code that's protecting the unsafe code could be the root cause for security issues, even if it manifests itself in the unsafe code.

Georgelemental2• 2 years ago

When using pointers in safe Rust, one is generally limited to tree structures.

For the sake of completeness, it's possible to express certain cyclic graph patterns without overhead in safe Rust. But it's usually too much of a hassle to bother with. https://docs.rs/ghost-cell/latest/ghost_cell/

burntsushi5• 2 years ago

Thanks. I had forgotten about `ghost-cell`.

29athrowaway2• 2 years ago

Rust started at Mozilla. Their products were written in C++, and despite all the effort put into good practices, they kept running into the same issues over and over. They designed a new language that would prevent those issues, and that became Rust.

Personally, I think C++ has too much cognitive load. Over multiple decades, many features were added and very few were removed. The result of that process is having code that reads like mixing Latin with Ancient Egyptian hieroglyphs and then followed by TikTok jargon.

humanrebar8• 2 years ago

Mozilla also has struggles staying competitive with its core products. The main criticism of Rust as a solution to safety concerns is about that kind of outcome.

Obviously Mozilla's challenges are multifaceted and don't boil down to user-invisible code rewrites. But, at best, switching to Rust was an orthogonal engineering concern that has opportunity costs.

dralley2• 2 years ago

Firefox is competitive, their struggle is primarily that their competition is Microsoft, Apple, and Google, who have both practically endless wells of money, control over the computing platforms, and vastly more mindshare.

There's no technical solution to that problem.

bsder3• 2 years ago

Personally, I think C++ has too much cognitive load.

I also think the same thing about Rust.

RAII adds a humongous cognitive load to a language and I'm not really sure what you do about that.

Zig is a step in the right direction with a bunch of the sharp corners in C filed down--slices and default non-null pointers is a big improvement.

However, there are some things (like reference counted data structures) that are really annoying to implement in C/Zig that are really easy to implement in C++/Rust.

29athrowaway2• 2 years ago

The RAII from C++ is a much larger burden.

spacechild12• 2 years ago

RAII adds a humongous cognitive load to a language

How does it add cognitive load? Compared to manual resource management it certainly removes a lot of cognitive load. And what is the alternative?

DrBazza4• 2 years ago

"How do I get to Dublin?" "Well I wouldn't start here"

I've been a c++ dev for 30 years. I'll be retiring in a decade (or perhaps keep going), and I doubt I'll ever see a 'safe' C++ in my working life.

If the committee were even truly serious they'd adopt epoch releases and feature flags in the language spec (see Circle, doing it for real), starting in c++26, the next release. And adopting tooling as part of the standard like every other language. As usual, C++ is the outlier here.

Then meaningful progress might start to be made in a measurable and testable way.

Instead I'll read another dozen articles like this for next 5-10 years, and any talk of tooling or epochs will be kicked down the road for another few years as usual.

But it's been a good lesson for all the other languages for better and worse.

tcbawo2• 2 years ago

IMHO, Herb Sutter was spot on in his talk (https://youtu.be/fJvPBHErF2U) that it is impossible to walk back features of a language once they are in the wild. His cppfront is an interesting and refreshing approach. I think his “create a TypeScript for C++”, ie. generate safe, easy to understand, conforming C++ is the optimal path for where we are. Dealing with legacy codebases to evolve the language into something else is monumentally more difficult. And I tend to argue that maintaining legacy C++ systems with decades of features and bug fixes is okay for the right applications today.

DrBazza4• 2 years ago

That's Hyrum's law, basically.

With feature flags and epochs, it is possible to evolve C++ in the right direction with the minimum of friction and make it opt-in in a consistent fashion. Circle already proves this a feasible approach, and that's a one-man project. There's also clang tooling that modernizes old C++, and huge amounts of work on LSPs and the like for refactoring, so it is possible to provide tooling that mechanically fixes-up a large portion of old code.

jandrewrogers• 2 years ago

In recent versions of C++, circa C++17 but especially C++20, it has become possible to build an alternative implementation of the language from within the C++ that makes a different set of guarantees and tradeoffs. This comes at a cost of no longer being able to use the standard library, particularly the vast legacy parts.

This is how I expect the issue to be addressed because there is too much invested in backward compatibility. Some C++ development, usually around high-performance high-reliability systems, already operates this way to a significant extent, using an alternative re-spin of the language primitives from the ground up that make stricter guarantees and enable greater composability and verification. C++20 in particular makes a nice base for building this.

You won't be able to force people to do things in a rigorous way, but providing a complete alternative goes a long way toward enabling safer code. I've seen alt standard C++ reduce bugs by an order of magnitude in real code bases (generally, since memory safety bugs are pretty rare in modern C++ in my experience).

8f2ab37a-ed6c2• 2 years ago

Any advice on how to write modern C++20 while avoiding all of the usual pitfalls, if that option is already available to C++ devs as of today? Is there a "C++ in 2024, the good parts" type of resource one could learn from?

DrBazza4• 2 years ago

C++20 doesn't stop someone writing new/delete/malloc/free, or using pointer arithmetic. For me to be sure your code is 'safe', I'd have to audit it visually, and that's the worst of all worlds.

The rigor can be put in the tooling, at the compiler level, as a flag. Then there's no 'forcing', it's just not possible to do certain things. Which is what is being advocated.

Hoisting it a level further, to the build system, means downstream dependencies can (also) be compiled 'safely', or required to be safe, by default.

Sticking a [[safe]] attribute into the language for regular source files would be a disaster. What's the point of one safe function in a library when the rest of it isn't safe?

Having said all that, I don't disagree with anything you've written regarding idiomatic c++20 reducing safety issues, it's just that it's a problem that can be and should be addressed mechanically in the tooling. I'm just really, really, doubtful that C++ will ever get anywhere near 'safe' in the next decade, or, really, next couple of decades.

htrp• 2 years ago

Also Unsafe for those under the age of 18 /s

CyberEldrich• 2 years ago

“We must make our software infrastructure more secure against the rise in cyberattacks (such as on power grids, hospitals, and banks)”

How about not connecting your critical infrastructure directly to the Internet.

AlotOfReading• 2 years ago

We have to work with the world that is, not the world that ought to be. Critical infrastructure is going to continue being accessible, so the people in charge of implementing those systems should have the appropriate tools to deal with the challenges it entails.

ergonaught• 2 years ago

The cognitive burden of developing in C++ anymore is excessive, but that appears impossible to recognize without completely stepping away from the language for a few years.

I loved the language; I even used it for web development for a couple of years and it was enjoyable to do so; but I did step away, and at this point I'd rather use Rust (a language I neither love nor find enjoyable).

Not sure the C++ committee have the capacity to "fix" this (whatever that may mean), nor whether the industry would let them, even if they were able to recognize the cognitive burden as a problem.

pjmlp16• 2 years ago

There is a certain masochism and macho attitude in C++, see the C++ frameworks of the 1990's like OWL, VCL and CSet++, where C++ was as expressive as you could expect from a .NET or Java framework a decade later, something that only lives on C++ Builder and Qt/QtCreator.

Both not really welcomed in most C++ circles, where naturally one codes close to C, with a thin layer abstraction wrapping OpenGL/Vulkan/DirectX in imGui for the ultimate performance, meanwhile the same authors use an Electron based application to write their code.

This is what made eventually move away into managed compiled languages, C++ isn't really the same as used to be, my next favourite programming language similar in spirit to Object Pascal, as in the last century of desktop GUI frameworks.

fulafel3• 2 years ago

We're lucky that the LLM stuff came about after C++ was already in decline. Or could there be a resurgence of C++ if we can teach LLMs to tackle what humans can't?

jvillasante• 2 years ago

While other communities are already taking direct steps towards safety, the C++ community is still trying to define what safety means. I think it's funny and sad at the same time!

I didn't read the article (just browse it) but here's the TLDR from the article itself:

``` tl;dr: I don’t want C++ to limit what I can express efficiently. I just want C++ to let me enforce our already-well-known safety rules and best practices by default, and make me opt out explicitly if that’s what I want. Then I can still use fully modern C++… just nicer. ```

As is normal in C++, the defaults are wrong. Developers should "opt in" for unsafe instead of "opt out" of it!

soulbadguy8• 2 years ago

Developers should "opt in" for unsafe instead of "opt out" of it!

Why ? C++ guiding principle is zero cost abstractions.

estebank3• 2 years ago

It's "zero cost abstractions over what you would write by hand". If you argue that anyone doing array access should be doing bounds checks when in doubt, a C++ compiler performing bounds checks would still be considered zero(additional)-cost.

spacechild12• 2 years ago

As is normal in C++, the defaults are wrong. Developers should "opt in" for unsafe instead of "opt out" of it!

Isn't this exactly what he is saying?

saagarjha5• 2 years ago

Another day, another essay from a C++ guy who is salty that the government called it insecure and thus seeks to compare the best possible version of C++ with his misunderstanding of what everyone else is doing, and doing a poor job at that too.

The stuff Herb mentions as solving "98% of the problems" do not do that. First of all, they don't do that now, because they aren't on by default. At least he accepts this, but people have been claiming that C++ is great now because all these things are easy to do, and the fact is that nobody actually does it. Every other language is shipping this as table stakes and C++ hasn't even gotten its pants on yet. Second, in the surfaces that do actually care about this (think web browsers) they are putting a huge amount of time and money into solving this regardless of what the language does by default. We're talking automatic initialization, bounds checks enabled by default, all sorts of smart pointers and "production" sanitizers. They are still being exploited. Yes, your average script kiddie isn't taking down Chrome these days. But nation states still do it. They don't care that you go to 98%! They find a bug, they exploit it.

The rest of the post is just the usual talking points against every other language that exists. A lot of it is wrong. I'm not going to dwell on the whole "Rust takes CVEs that C++ doesn't" argument because I think this misses the point, personally (Rust has a different safety model, so problems under that safety model are just as valid problems with Rust. You can't go "oh we are safer by default" and "oh actually this makes things a lot harder for us so don't judge us when things are broken). However, a lot is just wrong. Languages that do not corrupt their VMs on races are better in many ways than C++, because in C++ anything of that sort is basically a direct path to code execution. In other languages you have to work for it. In Rust people use unsafe–but that doesn't mean it's automatically as unsafe as C++. It just means that people write a little bit of code using it and then build on top of it. In garbage collected languages the runtime gets super upset if you hold on to references when it thinks you shouldn't. However, doing this is a performance and in some cases an issue of leaking resource. It is not comparable to, say, a UAF in C++. Basically, you can't just go "oh every other language has [problems I looked up on Google] this means they are also bad". Because in C++, the problems almost invariably lead to a foreign government taking control of your phone. This is not true for other systems.

alchemio• 2 years ago

So rewrite the browser in Rust!

Rust is 10 years old this year, yet there are no production level browsers or operating systems written in it!

I’m talking about Google. They come up with article after article about the failings of C++, yet would prefer starting their own programming language Carbon, continue using C/C++ for chrome, zircon and android.

saagarjha5• 2 years ago

Google is investing in bringing up Rust in the latter. Carbon is by another team, of which there are many at the company.

posix_monad• 2 years ago

Replacing circular structures with IDs is memory-safe, but it can still blow up if there is no item with that ID. It may be safer, but it's not guaranteed correct or anything like that. In these cases I'm not sure what is gained by Rust over C++.

Filligree• 2 years ago

The... memory safety? It will reliably blow up; that's quite an improvement already, when the alternative may be remote code execution.

There's also of course everything else, like the ergonomics, freedom from data races and so on, but I'll skip that.

hgs32• 2 years ago

Whether software blows up or not if an ID is "bad" depends on how it's written. Writing a token to a database without cleaning it up could lead to a security hole that has nothing to do with memory exploitation. I worry the fixation on memory is creating tunnel vision.

deathanatos3• 2 years ago

I'm actually surprised their example wasn't the accidental use of a valid ID, not an invalid one. An invalid one is easily catchable, but an invalid one is akin to a bad pointer. The resulting behavior will slip by the Rust compiler, as we're basically using integers as pointers, and you can get all sorts of shadow-clone versions of malignant pointer behavior like use-after-free in such a scheme.

That said … there are ways in Rust to do circular data structures that don't have the problems that using indexing into an array has, and are memory safe, and are within the safe subset of Rust. (E.g., Rc/Arc.)

estebank3• 2 years ago

That depends entirely on the implementation and use case. An append only arena, like is used in compilers, do not have ever invalid IDs by construction: you get the ID back after inserting into the arena and have no way of removing the value after that. For a use case where arbitrary removal and editing of existing values is needed, generational arenas are used so the handle encodes the "generation" of the value. If on access the generation doesn't match, it means the same as a null pointer and you won't get a value back, in a language with sum types represented with a None sentinel.

Disregarding entirely the memory safety aspects of turning a pointer access to an index access, there are benefits for using arenas (or struct of arrays) like better cache locality on access/avoiding memory fragmentation, and bunching values that don't outlast each other into a single free operation.

flohofwoe• 2 years ago

"Blowing up" immediately instead of corrupting random memory locations is pretty much what's desired though. Everything else is just icing on the cake.

richrichie• 2 years ago

Why not just use Go?

soulbadguy8• 2 years ago

too slow...

pjmlp16• 2 years ago

Fast enough for large majority of projects on CNCF project landscape, where C and C++ are a minority.

pptr7• 2 years ago

Go is a great language, but there also needs to be a language that you can program with zero overhead.

vlovich12313• 2 years ago

Many of the most damaging recent security breaches happened to code written in MSLs (e.g., Log4j) or had nothing to do with programming languages (e.g., Kubernetes Secrets stored on public GitHub repos).

I’m surprised Herb is so defensive here. He normally strikes me as level-headed but he’s arguing in bad faith here. There’s no way a language can prevent arbitrary code execution if the programmer intentionally wants to allow it as a feature & then doesn’t think through the threat model correctly or not managing infrastructure secrets (the latter btw is mitigated by Microsoft’s own efforts with GitHub secret scanning although there should be more of an industry effort to make sure that all tokens are identifiable).

But C/C++ is a place where 60-80% of the vulnerabilities are regularly basic things the language can mitigate out of the box. No one is talking about perfection. But it’s disappointing to see Herb stuck and arguing “there’s other problems and even if memory safety is an issue Rust has problems too”. The point is that using Rust is a step function improvement and provides programmers with the right tools so they can focus on the other security issues. A Rust codebase will take more $ to exploit than a C/C++ one because it will be harder to find a memory vulnerability which is easier to chain into a full exploit vs attacking higher level stuff which is more application specific.

EDIT: And language CVEs are a poor way to measure the impact of switching to Rust because it’s the downstream ecosystem CVEs that matter. I’m really disappointed this is the attitude from the C++ community. I have a lot of respect for the people working on it, but Herb’s & Bjarne’s response feels like an unnecessary defensive missive to justify that C++ is still relevant instead of actually fixing the C++ ecosystem problems (namely their standards approach is making them move too slowly to ever shore up their weaknesses).

nindalf22• 2 years ago

Their defensiveness makes sense in the current context where in the last few weeks organisations like the White House [1] and Google [2] are explicitly calling out the importance and imminent need of moving away from memory unsafe languages like C and C++. If everyone focussed on this one issue, it is possible that we might actually start moving away from C and C++ in the next 5-10 years.

Sutter pointing out that memory safety isn't the only vector for system vulnerabilities would have the effect of spreading cybersecurity efforts and budgets across all of them. In that case memory safety isn't the foremost problem it's being portrayed as, and it isn't worth migrating away from C and C++.

[1] https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-...

[2] https://research.google/pubs/secure-by-design-googles-perspe...

steveklabnik10• 2 years ago

The White House reports also acknowledge that memory safety isn't the only issue, but instead, is a large one that movement can be made on. From page 8 of that report:

To be sure, there are no one-size-fits-all solutions in cybersecurity, and using a memory safe programming language cannot eliminate every cybersecurity risk. However, it is a substantial, additional step technology manufacturers can take toward the elimination of broad categories of software vulnerabilities.

And of course, Google as well.

Not even the most fervent memory safety advocates believe that it is the sole thing that will make software secure, so arguments like this come across a bit strange.

infamouscow5• 2 years ago

The Whitehouse report should scare the shit out of anyone invested in better software. People think the report is a step in the right direction, it's not.

You do not want the blob of D.C. putting their eyes on anything that looks like a bottomless money pit for consultants and self-proclaimed experts. Once that happens and is codified to some degree in law, it's very difficult to change or remove.

This potentially affects every government system in existence, and those systems are already some of the most legacy systems today. The US Navy still pays Microsoft to maintain support for Windows XP, so the idea this will happen in any less than a 25 year horizon is absurd. And even then, the dates can be extended. Why put a stop to the gravy train when it can keep going -- it's not like the public is even aware of just how enormous the federal government really is. Once you understand this an opportunity to extract billions of dollars from large organizations, you then have to ask what their lobbyists will do to change the laws in their favor to completely neuter the legislation codified into law.

I haven't see anyone even consider this highly likely, if not almost certain outcome.

jcranmer4• 2 years ago

The table stakes here is automatic bounds checking. This is something that pretty much every newer language does already, and even several older languages figured out how to do well.

The problem in C/C++ is that pointers don't inherently communicate their bounds, so your options for adding automatic bounds checking are a) fat pointers and consequently (severe) ABI break; b) some sort of shadow memory to store bounds info (ASAN, generally considered inadvisable to use in production); or c) change the language to communicate what the bounds of a pointer are. The good news is that most interfaces will provide the bounds of a pointer as another member of the struct or the function parameter it's part of; the bad news is that actually communicating that information requires a scope lookup change that is hard to get through the committees.

physicsguy3• 2 years ago

The reason they don't communicate their bounds is also a performance optimisation. You can certainly do it in C++; use a std::vector for e.g. and use the .at() method to index on it and it'll throw an exception unless you disable that with a compiler flag.

The thing is, it's fine to take that risk if you're writing HPC simulation software, but it's much less fine if you're writing an operating system or similar.

pizlonator15• 2 years ago

Things like CHERI, Fil-C, and CCured make pointers just carry their bounds.

It’s not an unfixable problem.

I wish we were talking about fixing it, not making excuses.

uecker2• 2 years ago

The problem is existing practice. GCC has solved this problem for function parameters a long time ago with parameter forward declarations. But other compilers did not copy this GNU extension, and also nothing else really emerged... This makes it hard to convince the committee to adopt it.

In structs there is no existing extension, but a simple accessor macro that casts to a VLA type works already quite well and this can be used by refactoring existing code.

There are still some holes in UBSan, but otherwise I think you can write spatially memory-safe C more or less today without problem. The bigger issue is temporal safety, so the bigger puzzle piece still missing is a pointer ownership model as enforced by the borrow checker in Rust.

rerdavies2• 2 years ago

The problem is fixable in C++. std::span is the fat pointer; std::array is the checked array. All that's missing is a compiler option that gives warnings/errors when the legacy native [] features are used.

C is probably unfixable. But that's a different language.

Presumably compilers would allow conversion of spans to native pointer arguments when calling methods declared as "extern 'C'".

deathanatos3• 2 years ago

although there should be more of an industry effort to make sure that all tokens are identifiable

There is, BTW: https://datatracker.ietf.org/doc/html/rfc8959

Getting people to use the standard is another matter.

WalterBright• 2 years ago

C and C++ could both easily add this feature:

https://www.digitalmars.com/articles/C-biggest-mistake.html

which is adding slices to the native language. This will eliminate buffer overflow errors (if the user uses that feature). D has had this from the beginning, and while it doesn't cover everything, that feature alone has resulted in an enormous reduction in memory safety errors.

BTW, D also has a prototype ownership/borrowing system.

pptr7• 2 years ago

C++20 added std::span, which is essentially that.

JohnFen2• 2 years ago

The defensiveness is entirely understandable. There's a very vocal contingent of the industry who is increasingly hostile to anyone who dares to say that C/C++ isn't pure evil. Defensiveness is the natural reaction to that sort of thing.

vlovich12313• 2 years ago

Instead of defensiveness, why not talk about the ways in which the C++ committee is changing how they're operating (or even leaving ISO) and changing their culture to shore up these things.

Look at past Scott Meyers talks (e.g. [1]). He highlights how the committee has arbitrary set of principles that can be applied to justify or reject any proposal and the inconsistencies in the language are a reflection of this.

This isn't a problem of the language itself but rather that it's design by committee with 4 major front-end implementations (Intel, MSVC, Clang, GCC although I believe Intel is standardizing on the Clang front-end at least). Organizational issues like that are tough to spot but it's become clear now for several years that Rust is going to beat C++ silly if the C++ committee doesn't clean up their act and steer the C++ community a bit better (e.g. still no ABI specification, no improvements on macros, no standardized build system, modules are a joke, no standardized package system, etc etc). They're not effective stewards not least of which because they can't even take good impactful ideas from Rust and copy them.

[1] https://www.youtube.com/watch?v=KAWA1DuvCnQ

kwant_kiddo• 2 years ago

I think it is remarkable how important ABI is to C++. I think 'making it easier to enable them' i.e. enable the sane defaults went down the drain once they locked in on not breaking ABI.

I am sure that Herb wrote this with good intentions, but no concrete measures was proposed but trying to standardize compiler tools, and to some extent downplay Rust.

I agree there is a misconception around programming safety, but this reads the same as when big industry say the want to focus more on climate change.

morning-coffee• 2 years ago

I just can't help but have the feeling that the ship is sinking and this article busies itself with arguing over how much spackle is sufficient to plug one of the many holes. There is too much UB allowed in the C++ spec to be worth saving at this point. Focusing only on CVE reduction still punts on all the money and time wasted with buggy software because the language cannot do much to prevent data races, for example.

loeg• 2 years ago

C++ also brings the baggage of dogshit syntax and extremely verbose and confusing types and error messages that new languages do not suffer from. I get why this guy who has built his career in C++ is defensive of C++, and certainly existing codebases cannot be migrated overnight or even ever, but I would not start a new project in C++ if I could help it.

pizlonator15• 2 years ago

There isn’t too much UB for it to be fixed.

Fil-C fixes it (albeit just for C, for now). CHERI fixes it (and it works great for C++). There are other systems that fix it, too.

pjmlp16• 2 years ago

Unfortunely Intel and AMD keep shoting themselves in regards to memory tagging implementations.

layer8• 2 years ago

There is a huge amount of large C++ code bases out in production that won’t be rewritten in a different language anytime soon. Improving C++ from within there is a worthwhile strategy.

epage• 2 years ago

A lot of these improvements sound like the code will need to be rewritten anyways. Granted, it might allow for a more gradual rewrite.

fulafel3• 2 years ago

Yep. The parallel universe in which this could have been fixed in a sound way would have had C fixed first (bounded pointers, semantics of UB made similar to JVM, etc) and C++ would have adopted that.

jupp0r• 2 years ago

I have tremendous respect for Herb Sutter and I can understand where he is coming from, but things like

"All dereferences are null-checked. The compiler injects an automatic check on every expression of the form *p or p-> where p can be compared to nullptr to null-check all dereferences at the call site (similar to bounds checks above). When a violation happens, the action taken can be customized using a global null violation handler; some programs will want to terminate (the default), others will want to log-and-continue, throw an exception, integrate with a project-specific critical fault infrastructure."

make me just feel sad about the future of C++. The problem is not only CVEs, the problem is that the language makes doing the right thing hard and doing the wrong thing easy. All larger C++ projects I've worked on already use an enormously complicated and fragile combination of compiler-warnings-as-errors, static analyzers and linters to fix these problems and standardizing these is a worthwhile effort to reduce differences between different compilers and tools and to get to a bare minimum standard that everybody can agree on. The problem is that most projects won't adopt these until the 2030s or 2040s and then they will only create a bare minimum bar of safety and convenience when new projects could just use Rust and get a very well thought out safety model and other benefits (no inheritance, const-by-default, etc) at little extra cost.

The type system and metaprogramming capablities of C++ are really nice (when compared to Rust), but at this point the language is only relevant for the existing (thriving) codebases that use it and for historic reasons, but no sane person would choose it for an new project anymore, which makes me sad. I don't see how C++ can reinvent itself and stay relevant without a radical break that takes the last 20 years of language development into account. Also, finally put some coroutine compatible event loop in the standard library FFS, it's 2024.

ubj• 2 years ago

It's interesting to compare these opinions with those of the Google Security team that were released a little over a week ago [1].

Key quotes from the Google paper:

We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety.
In our experience, it is not sufficient to merely make safe abstractions available to developers on an optional basis (e.g. suggested by a style guide) as too many unsafe constructs, and hence too much risk of bugs, tend to remain. Rather, to achieve a high degree of assurance that a codebase is free of vulnerabilities, we have found it necessary to adopt a model where unsafe constructs are used only by exception, enforced by the compiler.

It seems like Herb Sutter at least partially agrees with the second point in his TL;DR:

I just want C++ to let me enforce our already-well-known safety rules and best practices by default, and make me opt out explicitly if that’s what I want.

[1] https://security.googleblog.com/2024/03/secure-by-design-goo...

soulbadguy8• 2 years ago

Rather, to achieve a high degree of assurance that a codebase is free of vulnerabilities, we have found it necessary to adopt a model where unsafe constructs are used only by exception, enforced by the compiler.

Yeah that sound like most security researcher i have talked/listen to. They see the problem as safety maximization problem. While in the real world, there are 50 different other constraints that a language design needs to navigate.

PH95VuimJjqBqy14• 2 years ago

We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety.

The point Herb was making is that "rigorous memory safety" isn't the only bar, nor should it be. Saying there is no way to make C++ have rigorous memory safety is not the same as saying C++ can never be made safe.

8f2ab37a-ed6c2• 2 years ago

Having recently had to pick up C++ again after over a decade in Ruby/Python/Clojure/Haskell/TypeScript land, it was enlightening to see how much the language is a window into a previous era of programming, full of boilerplate and footguns and dreams for programming patterns that ended up non panning out.

It feels like the programming community can do so much better, having seen the other side of it, but there's an immense amount of legacy code that's holding us back. Especially if you're going into more serious game dev territory, it seems practically unavoidable.

pizlonator15• 2 years ago

If there were 90-98% fewer C++ type/bounds/initialization/lifetime vulnerabilities we wouldn’t be having this discussion.

I disagree. We shouldn’t aim for 90-98%. We should aim for 100%.

Reason: unlike logic errors, memory safety bugs are exploitable more often than not. Logic errors are usually just some useless glitch and only sometimes exploitable.

rust has 6 CVE’s

Couldn’t quickly check if any of those six were memory safety or not.

It’s sad that rust still has memory safety issues and if that’s true then my conclusion is that rust isn’t safe enough.

steveklabnik10• 2 years ago

It’s sad that rust still has memory safety issues and if that’s true then my conclusion is that rust isn’t safe enough.

Let's assume all the CVEs are memory safety issues (some are not, some are, in reality.) Even then, they're things like "a bug in the standard library" that was then fixed. All software has occasional bugs. It is not possible to never have bugs.

aapoalas• 2 years ago

In workplace safety, at least in my country, there is a commonly accepted level to aim for: No accidents.

It makes sense in a way. If you don't aim for zero, what do you aim for? A few hands lost in a month? A few crushed fingers?

In this viewpoint I'd argue that aiming for a 98% reduction is a bit absurd: "Yeah we had an issue but it was the only one this month so it's within our budget."

Of course, goals are not the same as realised results. Getting a 98% reduction should be considered a huge, huge win. The next step should then be "what can we do to get rid of the rest?" Or at least the alternative seems odd: "We got this far, job done, nothing useful to do anymore."

Of course, the means will change. If C++ guarantees full memory safety next month, then the next steps after that won't be more memory safety but something else.

pizlonator15• 2 years ago

I think "bug in stdlib" is forgivable, and I wouldn't fault Rust for it, exactly for the reason you say. It would be a great outcome if Rust's compiler and stdlib became a trusted compute base and folks had to be extra careful there.

It's not a great outcome if there are memory safety bugs arising from how some Rust programmer did some stuff.

So, I would revise my statement to: "It would be sad if Rust had memory safety issues that any user of the language could run into, and if that was true, then my conclusion would be that Rust isn't safe enough."

jbiason• 2 years ago

not all code can be easily updated to conform to safety rules (e.g., it’s old and not understood, it belongs to a third party that won’t allow updates, it belongs to a shared project that won’t take upstream changes and can’t easily be forked).

I have to say, this sentence annoys the heck out of me.

Old code that can't be understood needs to be rewritten anyway. And since you're rewriting, you can apply the safety rules -- which would be better anyway.

If the code belongs to a third party and they don't want to update, it means the third party is playing against you -- or, worse, that they control how you're going to move forward. It's in your best interest, in this case, to rewrite the third party dependency as soon as possible, and since you're rewriting, you can apply the safety rules -- which would be better anyway.

If the code is shared and the upstream does not accept patches and -- worse -- doesn't support forks, then you have an issue with the upstream anyway and -- guess what -- you'd be better rewriting it anyway.

All those issues are managerial issues, not software issues. Management decided that it is better to be stuck than moving forward. And they can happen with any languages, not just C++.

Adding these things as "we can't be totally safe" are like "I can't jog every afternoon 'cause bears/alligators/wild life may jump an attack me". It's pure excuse to NOT do things.

PH95VuimJjqBqy14• 2 years ago

I have to say, this sentence annoys the heck out of me.
Old code that can't be understood needs to be rewritten anyway.

I don't think it's that old code can't be understood, you can always understand what code is doing mechanically.

it's a question of can you predict the consequences. For example, if I rename this database column, what in our systems that have been built over the last 30+ years will explode? That's data rather than code, but the underlying idea is the same.

What happens is the very act of rewriting it puts you at risk of adverse effects.

summerlight• 2 years ago

After using the modern C++ more than 10 years, I don't believe the "safe subset" is sufficient to solve the security problems in C/C++. It does help, but not enough to keep the pace of modern software complexity. Some of localized anti-patterns could be prevented, but any non-trivial memory bugs across team boundary won't be.

madmax96• 2 years ago

This post contains a number of statements that mislead the reader into believing that we are overreacting to memory safety bugs. For example:

An oft-quoted number is that “70%” of programming language-caused CVEs (reported security vulnerabilities) in C and C++ code are due to language safety problems... That 70% is of the subset of security CVEs that can be addressed by programming language safety

I can’t figure out what the author means by “programming language-caused CVE”. No analysis defines a “programming language-caused CVE”. They just look at CVEs and look at CWEs. The author invented this term but did not define it.

I can’t figure out what the author means by “of the subset of security CVEs that can be addressed by programming language safety”. First, aren’t all CVEs security CVEs? Why qualify the statement? Second, the very post the author cites ([1]) states:

If you have a very large (millions of lines of code) codebase, written in a memory-unsafe programming language (such as C or C++), you can expect at least 65% of your security vulnerabilities to be caused by memory unsafety.

The figure is unqualified. But the author adds multiple qualifications. Why?

[1] https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...

bfrog• 2 years ago

Safety as in undefined behavior isn’t in a subset of the language or safety as in memory safety? Because Rust tries to do more than memory safety and it’s quite amazing. Integer overflow isn’t an unheard of problem. The 787 had an integer overflow problem in C about a decade ago. The most recent drama with the entire FCU going dark seems eerily similar to what you might expect where a watchdog would reboot it.

lionkor• 2 years ago

We C++ developers like that C++ is easy to fuck up, because we think we know better, and we think that means job security.

C++ Safety, in Context

Related Stories