Hacker News Reader

Comment by carlmr | Hacker News Reader

>After all, I have worked for decades to make it possible to write better, safer, and more efficient C++. In particular, the work on the C++ Core Guidelines specifically aims at delivering statically guaranteed type-safe and resource-safe C++ for people who need that without disrupting code bases that can manage without such strong guarantees or introducing additional tool chains.

After all statistics just isn't on his side. Even the top engineers hired by Google create around 1 memory error every 1000 lines. And they didn't have one yet in 1.5 million lines of Rust [1] This is with all of the analysis tools at their disposal and in use for C++. And most companies can't afford the same top talent that Google can.

I've been working in safety critical software for a long time now. C and C++ will never be safe because their safety model relies on human infallibility. Ada and Rust IMO have the most potential here.

[1] https://security.googleblog.com/2022/12/memory-safe-language...

View on HN

Any improvements to C++'s safety are welcome, because there are huge and important existing C++ code bases.

Using C++ for a greenfield project today should require some very good justification though.

Exactly, For small-ish tools RiiR works, but not for large proven-in-use codebases. While a rewrite would probably squash memory errors you would often get logic errors because you forgot to port some condition.

I'm not against improvements to C++ safety, I just think making C++ a safe language has provably failed.

Real-world RiiR efforts generally start with smallish, security-critical modules within larger code bases. It's not a full rewrite from scratch, you can replace C/C++ with Rust even at the level of a single function.

That I'm completely on board with, you need to start somewhere.

Not rewriting, but starting anew. And usually you start (relatively) small. I see fewer and fewer reasons to start a new C++ project, except when the project makes heavy use of existing C++ code base anyway as large C++ libraries.

> Using C++ for a greenfield project today should require some very good justification though.

Having to maintain legacy C++ applications is all the justification you need to have to understand that staring greenfield projects in C++ is quite frequently and by far the best option on the table

It makes absolutely no sense at all to multiply the tech stacks that a team needs to work on, let alone master, just because naive platitudes have been said about any novel tech stack. You do not make any application better or more secure if you get clueless developers onboarding onto new technologies and forcing them to maintain N+1 code bases and 2*n bindings.

This irrational dislike of C++ ignores the fact that adopting the latest C++ release and toggling static code analysis in your project, which nowadays comes for free, already gets any project way ahead of where naive retractors believe C++ is.

I would agree that clueless developers are the issue, not the language. I have happily recently started a new project in C++ and amazingly it works, even without the latest faddish languages or tech stacks!

It is not possible to staff a team with perfect humans. Better tools remove the need for perfect humans.

> toggling static code analysis in your project

Except that security must be on by default, and it must be made hard (or shameful) to circumvent it. We all know any kind of protection is easy to bypass in C++.

I remember an article from a Julia developer quitting over the culture of using unsafe code that had installed in the community.

A mindset change is required by this profession. Too often (unverified) performance reasons have been used to justify risky code.

If you want to use statistics to support your assertion that C++ hasn’t gotten better, safer and more efficient over the decades then your statistics must compare different versions of C++, not C++ and Rust.

The blog you linked to is a PR piece. A real study would go in-depth and look at the quality of the C and C++, particularities of the affected subsystems (such as a requirement to interact directly with HW, etc), split findings by subsystem and components and also link snippets of source code to CVEs. Hopefully Google will publish such a study someday instead of a few pieces of data and graphs.

But that’s not the major issue.

You’re taking as fact that Google’s Android C++ programmers are particularly interested in safety or are significantly more competent than average. Based on my occasional perusal of Android C++ code in a professional context I cannot confirm either assumption: Android C++ is not modern (not even C++11 modern) and is very pointer heavy. It’s an eclectic mix of C functions and C data types with C++ constructs.

Take a look at some random fixes for CVEs that I took from the December security bulletin:

* https://android.googlesource.com/platform/frameworks/minikin...

* https://android.googlesource.com/platform/packages/modules/B...

That looks like C with classes to me.

Perhaps it’s for the best if projects such as Android or Chrome, etc are rewritten in Rust. Catching stuff after the fact with sanitizers, fuzzing, etc will never work if the code is ignoring or can’t use most of the advances that Stroustrup was talking about.

Google's code bases (and Microsoft as well), are a good example of even ISO C++ members, major contributors to C++ compiler ecosystem and static analysis tooling, still fail to achieve the security standards that Bjarne Stroustrup and other security minded folks keep advocating for.

Mostly because in the end they aren't doing what gets preached in spite of the in-house experts.

So how much hope have the regular C++ devs that don't take part in ISO C++ and compiler development tasks?

That's the really nice part of Rust, actually. The compiler will always barf if you don't do the right thing in Safe Rust, even by mistake. And even common but logically error-prone patterns, such as shared mutability, are clearly marked by boilerplate.

Nice part of any safe systems language, not only Rust.

Google is too big, working on too many projects which are released too often for the tools and processes to keep pace. They additionally have high turnover.

Under these circumstances, using C++ over decades has the results that can be seen - they can’t produce secure software.

I don’t think that Google or any other company can create secure products. I was actually surprised how many Java bugs were present in the December list.

The market, the incentives are not set up for that. Sure, using safe languages would help in a narrow sense, why not give it a try, but this is turning into scapegoating and silver bullet activism. Once they get rid of the most C and C++ code I bet their products will still be insecure, because the culture, the processes, the market and the people won’t have changed.

Ah, the typical when we get rid of the 70% memory corruption bugs, we still have to deal with the remaining 30%, so why bother.

By all means, bother with that and implement it. Then publish a proper study, so others could learn from it.

I guess I have been bothering with it since 2005, in which I have been part of teams that replaced C and C++ systems with managed languages (compiled), leaving them to essential code paths when unavoidable to do otherwise.

As Morris worm has proven, it isn't a good idea to have such languages process directly data from the network in distributed systems.

I thought you switched to managed because there were not enough low-level jobs available…

I would go further and say that Google's end software is pretty poor. Their Drive syncing software doesn't give indication on current progress and in Google Drive itself try to get the size of a directory and its contents - it's impossible. Worse usability than Windows 3.11 File Manager. The Android Studio software doesn't work with keyboard shortcuts in Windows (the focus gets lost somewhere so Alt-F never works); every update mentions some improvements on speed or introduces features that Visual Studio has had for decades; the update dialog shows a miniscule blob as a "notification" in spite of all the fanfare of usability they push. The guidelines for Android interfaces uses all their old guidelines as how not to do something. Their Lighthouse page checker fails if you run it on itself. Their documentation for AdWords API/SDKS is jumbled. The user interfaces on AdWords is horrendous. YouTube on the web loads slowly on the homepage and takes at least 3 seconds to be usable despite them penalising your website for doing the same. Their old desktop search software (anyone remember that?) was very poor. They change the way adverts are shown (the conditions under which they are shown) based apparently on the phase of the Moon and the world suddenly jumps to play their game to get adverts shown for what they want, eg. they show adverts for "traffic cone" even if the person searched for "ice cream cone" and you chose this to be an EXACT MATCH - some new definition of "exact" nobody else uses... Then it's not obvious how to integrate their software into your website that armies of people produce blogs and videos to demonstrate how to do it, which is a terrible indictment of Google's software usability. They exist solely for extracting money from their users AND customers, with nobody to talk to unless you spend exorbitant sums of money.

They simply don't follow their own advice and I don't think the tech world should be fawning over their proclamations half as much as they do. I am not surprised that they don't follow their own advice on C++ despite being on committee members - they don't follow their own bombastic statements on ANYTHING.

Like Larry Page appearing at the Android IO conference to much applause to berate Facebook for not federating XMPP and then the same day they turn off GChat access over XMPP themselves. They simply are not trustworthy against their own advice.

I wouldn't trust them to continue any software they write as they have a track record of chucking stuff in the bin after the initial announcement has faded.

But they do make a lot of money advertising to you and stalking you around the web.

> I would go further and say that Google's end software is pretty poor.

Sure, as is the vast vast majority software. I honestly fail to think of a GUI app I have ever used that never had any glitches during regular use.

Word? Excel? I have used them since the mid 1990s and can't think of when they've been as poor as Google's offerings.

I am not sure if the comparison is correct. Basically, they are looking at the Android code base and calculate 1 vulnerability / kLoc for C++. This doesn't tell us anything about the distribution over time. It could be that Google limited itself to certain C++ features in the beginning of Android and had or has a lot of vulnerabilities from this era, whereas newer code using smart pointers etc. doesn't suffer from this issues (as much).

It would be more interesting to compare only the code of C++ and Rust written in the same timeframe. My expectation is that C++ wouldn't look as bad as stated in the article.

People have investigated this too. Smart pointers, even the ones created specifically for Chromium, have not eliminated these problems. You can happily find CVEs whose root cause is a UAF on an object managed by unique_ptr in the Chromium codebase.

I would be really interested in seeing such a case where there was no extraction of a raw pointer or similar involved. Could you please point me to such a CVE?

Of course there is extraction of a raw pointer or reference. But that's a perfectly normal way of writing C++. An object that owns something hands a non-owning pointer to another thing with the assumption that the owning object will outlive the thing that uses the pointer. But people make mistakes and fuck up lifetimes and then you have a UAF.

If you never call .get() on a unique_ptr then you'll be okay. But that's often not a workable design.

> Of course there is extraction of a raw pointer or reference. But that's a perfectly normal way of writing C++.

No, it isn't. That's flagged by default settings of most static code analysis tools, and it requires explicitly going against the whole point of explicitly assigning ownership of an object.

Ownership is about lifetimes, not use. You are going to have a highly constrained design if nothing can access any pointer that it does not directly own.

Which static analysis tools? Can you point me at them? Maybe a sample program demonstrating that it'll throw out up loud warnings when I pass a reference to an member owned by a unique_ptr to another function? Like, are there any static analysis tools that warn on every single string_view parameter?

> Ownership is about lifetimes, not use.

You're failing to understand that granting access to the raw pointer managed by a std::unique_ptr violates the precondition that the object owned by that smart pointer is managed exclusively by the smart pointer itself.

It's very strange how you fail to get this point when you're trying to complain about C++'s supposedly memory management issues in general, and in this particular case an error sparking from violating these invariants.

Failing to use a smart pointer, to the extent you even have to explicitly ignore errors from static code analyzers to make them, is not a language issue. It's a "pay attention to the big red error messages" issue.

You can't have your cake and eat it too. It makes absolutely no sense to spend so much time and energy mindlessly criticising a programming language to then try to argue that making one of the most basic errors was somehow an acceptable practice when it clearly isn't.

You didn't answer my question. What static analyzers? "Never pass a non-owning reference to anything ever" is ludicrous.

Google's answer to this issue seems to be... a smart pointer: https://chromium.googlesource.com/chromium/src/+/main/base/m...

> It would be more interesting to compare only the code of C++ and Rust written in the same timeframe. My expectation is that C++ wouldn't look as bad as stated in the article.

I agree. The article reads like it started with w conclusion and cherry-picked data to fit that.

Thanks for sharing this. Wow, its a really suprising statistics to see 0 vuln found in 1.5m loc, even with Rust.

I personally expect there are still some unfound memory errors in there, but it's such a stark contrast to C++ it's amazing.

However memory errors in C++ account for 70% of vulnerabilities. I'd expect 30% to thus remain.

Edit: meant to write memory errors not vulns.

It's new code, there must be some logic errors, off-by-one errors, assumptions not expressed in the code etc. But that's not saying much, all new code has issues.

The good thing is that since this code was written in a memory safe language, at least that eliminates an entire class of bugs.

Zero memory errors, not zero vulnerabilities.

In high-quality C and C++ projects, about 70% of vulnerabilities are caused by memory errors. (https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...)

Not zero vulnerabilities, zero memory errors. Memory errors make a good share of vulnerabilities, but not all vulnerabilities are memory errors. And not all memory errors are vulnerabilities, sometimes it is just an inexploitable bug.

It is to be expected that there is no bug in the very thing that Rust is supposed to prevent. The same can be said of Java, JS or even PHP. What surprises me a little though is that there is zero memory error even in unsafe Rust. There has to be some unsafe code somewhere, for low level data structures and things like that.

>What surprises me a little though is that there is zero memory error even in unsafe Rust. There has to be some unsafe code somewhere, for low level data structures and things like that.

Even unsafe Rust has more strict typing and borrow checking which C++ doesn't have. It does allow raw pointers, but it's still safer than C++.

The other thing is that if say 1% of your loc is unsafe Rust, it's much easier to put this under more scrutiny than the whole C++ codebase.

And 1% is a lot if you ask me. I almost never need unsafe at all.

>There has to be some unsafe code somewhere, for low level data structures and things like that.

In most cases you can just use the standard library code for these. They do contain unsafe of course, but it's in one of the most battle tested places.

Is that 1 in 1000 for all C++ written since 1985, or is it "like for like" and all C++ written since 2010 when Rust first appeared or later when Rust stabilised?

Chrome was 2008. No idea if the code base has been completely "modernised" or not.

I just cringed when I saw C++ and safety in one sentence. This is good statistics to showcase gut feeling, thanks.

I presume you're using an operating system and browser written in Rust? If not, it would seem that the C/C++ based operating systems and browsers that you are use are perfectly safe to use, no??

Those OSes and browsers do show memory safety issues time and time again.

They are some of the most hardened codebases, and still fail in light of the issues with C and C++.

Exactly.

The languages are not at fault. The fallible users of them are.

This is identical to me writing a garbage sentence in English and then proclaiming that English as a language is wrong and needs to be replaced because it's perfectly possible to write something grammatically incorrect in it.

Surely you can see the difference but are conflating use of the language with the language itself.

Published last friday - https://seclists.org/oss-sec/2023/q1/20

Oodles of vulns in linux that are made possible by C's lack of safety guarantees.

> Oodles of vulns in linux that are made possible by C's lack of safety guarantees.

I'm sorry, isn't your link about how a user found a memory error in the Linux codebase? It seems way farfetched to jump to your conclusion from that starting point. I mean, doesn't Linux have over 12 million lines of code right now?

It is one example of gazillions. I chose it because it was published a few days ago.

We've somehow as a community just come to accept that linux will be riddled with security vulns. This is incredible to me, as the security of an enormous number of our applications depends on the kernel being secure. What ratio of vulns to lines of code in linux would you find acceptable?

> It is one example of gazillions.

It's literally a single memory error in over 12 million lines of code.

What exactly was the point you were trying to make?

> We've somehow as a community just come to accept that linux will be riddled with security vulns.

I'm sorry, your claim is pure nonsense detached from reality. What exactly led you to believe it's reasonable to jump from finding a single memory error among over 12M loc to "riddled with security vulnerabilities"? Linux quite literally dominates the list of most secure OSs. Where exactly do you base your personal assertion?

Vulns are found at a roughly uniform rate.

I mean, we can go search the CVE database for the linux kernel. Surely you don't think that this is the only vuln ever discovered there?

> Vulns are found at a roughly uniform rate.

I'm sorry, this means nothing.

As you made extraordinary claims regarding the security of Linux, did you based your personal assertion on any real world comparison between OSes? Because so far you failed to provide any support for your claim, beyond pointing out a mailing list thread on a single memory error in a RC1 within a 12M loc codebase.

What number of vulns would be acceptable to you?

> What number of vulns would be acceptable to you?

Please stop trying to avoid the question.

Either you based your personal assertions on concrete data, or you're just a clueless troll spewing baseless nonsense.

You've repeatedly tried to dance your way out if substantiating your extraordinary claims.

Either you're able to come up with any semblance of support for your claims, or you can't. What is it?

Here are 2,300 CVEs in linux. https://www.linuxkernelcves.com/cves. You can wander through and look for terms like use-after-free and buffer overflow.

I'm not comparing it to other operating systems. I'm not suggesting that people stop using linux. I'm suggesting that as an industry we need to take this seriously and improve the safety of the most widely used and critical piece of software on the planet.

> Here are 2,300 CVEs in linux.

I'm not sure you're being serious. Do you understand your list is comprised of CVEs that date way back in time as far as 2003?

You're talking about an unfiltered, uncategorized list of reports that were published in last two decades.

At least a couple of entries from a decade ago referred to fixing kernel warnings.

And that's what you chose as the single best smoking gun to support your personal assertions on C?

I have no idea what you want. Will you give me a description of what sort of vuln counts as meaningful to you? First you complain about a single example. Then you complain about a list that is too wide (you can filter it if you want). How am I supposed to do anything useful if I have no idea what you want?

> I have no idea what you want.

I want you to either substantiate your extraordinary claims regarding C's supposedly security issues along with your personal assertions regarding Linux supposedly being riddled with security vulnerabilities. So far you either desperately tried to avoid the questions or put up strawmen. Either you support your claims and present your rationale or your claims are proven to be nonsense.

Nonsense links to 20 years worth of CVEs that boil down to an average of a few dozen random issues in a codebase of over 12M lines of code is complete nonsense, and showcases the exact opposite of your original claims, not to mention that most have zero to do with C at all.

So exactly where do you base your personal assertion that C is somehow riddled with security issues? Nowhere?

People like you need to either open your eyes and think through your baseless beliefs or stop being disingenuous. The world is very different than the bullshit claims that pops up in your Twitter feed.

I don't think anyone believes that Linux will be "riddled with security vulns" nor do they think it's acceptable.

It would seem you have a war to wage on C for periodic bugs written by users of the language, and are ignoring the colossal amount of perfectly decent, working, good code written in C and C++.

This sort of thing seems to happen whenever there's an article on C/C++ and it's wearisome. Many people suddenly appear and proclaim that the languages are terrible and should die and mumble something about memory safety, when I myself haven't got any problems writing memory-safe C++ and haven't had any problems for decades.

Sure, some others do but it doesn't mean the LANGUAGE is terrible; it means the USERS of the language make mistakes. On further investigation, a lot of the vocal haters of C++ turn out to not really use the language that much and therefore means the vocal whining about the language has as much relevance as me complaining about masculine/femenine/neuter when I get der/die/das wrong in German when I only learned it at school decades ago and never ever use it - that is, completely irrelevant. People would rightly roll their eyes if I started complaining about der/die/das when I used it wrong in a sentence.

As a simple analogy, whenever there's a car crash we don't see thousands of people saying that cars should be banned and replaced by trains because "cars are dangerous!"; we understand that the USERS of the cars are at fault, NOT the cars themselves. The same is true with C/C++ - you can make mistakes but you can make dumb mistakes in ANY language. That's why programming is a practiced skill and not something you learn overnight.

There exist C and C++ projects that have zero memory safety vulns. There also exist C and C++ projects that don't operate on untrusted data and so the consequences of a memory safety error are just crashes.

I don't believe that the Chrome or Android developers are especially unique developers. I think that they are a decent proxy for a typical developer on a large project that has significant adversaries. These projects are developed by companies that use better-than-typical tooling to detect vulns.

So I believe that these projects are good examples of what you can expect from ordinary developers using the most recommended safety tools. And... they are full of vulns. If you own a project that is developed entirely by extremely skilled developers or has no significant security characteristics then that's different. But if some person is hiring a bunch of engineers to build and maintain a project that has nontrivial security implications, I think that these projects are decent proxies for the best you can hope for.

I do not believe that it is possible to train an org of developers to safely write a complex project that has nontrivial security implications in C++.

I've been writing C++ code for well over a decade and a significant portion of my career involves static analysis of C++ code. "The haters just don't use C++" is not a compelling argument, in my opinion. In fact, you can find members of the C++ committee who agree that it isn't acceptable for the long term safety of software. Surely they "use the language."

---

Analogies won't ever produce meaningful argumentation here. You can say that Rust is a train and that C++ is a car. I can say that Rust is more like a car with a bunch of modern safety features like lane assist and anti-lock brakes. That's not going to get us anywhere.

Very interesting reply, thanks. I am not sure how much C++ some of the book writers actually write - some of their advice and patterns don't seem usable in the real world.

I should say that the majority of very vocal "haters" that appear on C++ topics appear to not use it and instead just show up to burn the C++ flag in a public space.

>"1 memory error every 1000 lines"

One memory error per 1000 LOC? I think they probably either use old style C++ or something else weird and ignore all static and runtime memory safety tooling to get to this error rate in their releases.

>"And they didn't have one yet in 1.5 million lines of Rust"

I assume that those 1.5 "million lines" do not contain any unsafe features Rust allows for. Am I correct here?

> I assume that those 1.5 "million lines" do not contain any unsafe features Rust allows for. Am I correct here?

I would assume that there are a few `unsafe` lines of code in these 1.5 MLoC. Which still makes it easier to trust than 1.5MLoC of C++ in which (by Rust definitions of `unsafe`) every line makes use of `unsafe` features.

(insert usual caveats about tradeoffs, etc.)

> One memory error per 1000 LOC?

From his link: "Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) in many of Android’s C/C++ components (e.g. media, Bluetooth, NFC, etc). Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production."

As already said this error rate for released code seems way too high. No idea what they're doing internally but they definitely doing something wrong. Probably sticking to old style with lots of explicit memory management.

Yeah, but that is the thing, most C++ shops write code exactly like that, regardless of what a few iluminated souls write about modern C++ and static analysis best pratices.

Not even Bjarne's continuous preaching seems to affect current practices, as most folks don't do social activities regarding their day job programming languages.

But that's not the language's fault. As a C++ developer I worked with developers who were scared to use the STL and were using MFC containers in 2017. Still using Visual Studio 2008 because it would take a mammoth task to move the 6.5 million LOC to a modern IDE. They eventually did it when I left but even the senior developers were oblivious to C++11 features like move semantics, lambdas etc. Hopeless.

It's not the fault of the language if developers are lazy or use the tool badly.

Yeah it's not quite language's fault if the language provides a better way to do the same . But equally, the language does provide a bad way to do things. A developer in a hurry, or a developer trying to follow the existing convention in the code base, or a developer making a reasonable assumption that's later invalidated - there's no sense in blaming these folks either. We can admonish them all we like, but the bugs keep appearing.

I think it's better to be hard on tools, not people. We can make give the people better tools. Telling them the tool is fine and the problem is with them isn't productive and doesn't lead to better software.

It is not the car's fault if people manage to crash and die by not using ESP, ABS and seatbelts.

> I assume that those 1.5 "million lines" do not contain any unsafe features Rust allows for. Am I correct here?

Because as Rust grows it is easier to model more behavior and less unsafe is needed. They mention this in the article.

> There are exactly two uses of unsafe in the UWB code: one to materialize a reference to a Rust object stored inside a Java object, and another for the teardown of the same. Unsafe was actively helpful in this situation because the extra attention on this code allowed us to discover a possible race condition and guard against it.

> In general, use of unsafe in Android’s Rust appears to be working as intended. It’s used rarely, and when it is used, it’s encapsulating behavior that’s easier to reason about and review for safety.

https://security.googleblog.com/2022/12/memory-safe-language...

Reply on news.ycombinator.com