Hacker News Reader

Comment by ghostwriter | Hacker News Reader

> and argue that this means it's not worth the hassle of switching to a new language.

Defenders of C++ argue that there's no reason to change the language, because new features around safety guarantees are being introduced into every C++ standard starting from C++11 at a remarkable pace, so remarkable that compilers implement them faster than the existing adoption rate. And the adoption rate speaks volumes about existing capacity to port/rewrite big codebases in entirely new stacks. The new stacks also tend to have fewer custom static code quality analyzers from third-party vendors, and they are used a lot in mission-critical C++ codebases.

View on HN

> The new stacks also tend to have fewer custom static code quality analyzers from third-party vendors, and they are used a lot in mission-critical C++ codebases.

Are these static code quality analyzers detecting code quality problems that Rust and company are also vulnerable to? Or are they mostly looking out for the hundreds of legacy footguns that C++ still officially supports?

They focus on quality control and compliance to safety requirements in specific domains and industries, for instance MISRA.

This might be of interest https://github.com/PolySync/misra-rust

Google is one of the biggest C++ shops out there, and also authors and maintains many of the static analysis tools and safety features you mention.

If they’re saying that C++ can’t be saved, maybe they’re worth listening to.

> If they’re saying that C++ can’t be saved, maybe they’re worth listening to.

It might be true, but it also sounds like an appeal to authority. I suspect there also might be voices that are being silenced or aren't given a similar platform to speak up and provide an alternative viewpoint on the matter within the same organisation, because <team budget/political reasons why>. After all, there are greenfield projects that are being started in C++20 and people are enthusiastic about their prospects. I wouldn't just blindly dismiss their reasons in favour of Google ones.

C++ is needlessly complex and puts too much of a cognitive burden on the developer. I just wasted a day of my life traced to an errant semicolon in a legacy cpp base. I've used the language for 20 years. It can't be saved.

No offense, but I haven’t heard if people wasting days in semicolons outside of memes and really junior developers. What was the issue?

In real-time systems with millions of lines of code, no debugging capabilities outside of logs, and user misuse use cases, you'd be surprised what can lurk beneath.

In my experience, a good, auto, code formatter helps alot. You can’t hide a semi colon from code formatter.

Are you suggesting a code formatter as a mechanism for static analysis? There are really good tools like coverity, and free ones like cppcheck and clang-tidy that will catch that and so much more. Using c++ without cppcheck and clang-tidy in your cmake and pipeline is like leaving the seat up. It takes so little time, and the benefits to others is great.

That said, they won't catch a ton of memory and thread safety issues. You'll need tests with 100% coverage for that. Or you could just write it in rust and the compiler will catch it.

If it was about a semicolon it even sounds more like running with not all warnings on. C++ is "bad" (shorting a lot) due to its compatibility being able to also compile last centuries code.. but if today on active code bases you are not even running with at least that, why would you ever switch to Rust?

And full agree, all what cppcheck does imo should have long gone into the warning suite, and Werror and Wall should be the default..

An appeal to authority is a fallacy because it doesn’t actually mean anything. It’s false credibility.

If the authority comes along with a bunch of well researched and documented data from experiences in the real world… that seems worth listening to.

It’s no longer an appeal to authority. It’s just looking at evidence.

They’re not saying that C++ can or can’t be saved. And there’s no “they”, there are hundreds of teams with different expectations and policies.

You’re merely reading what you want between the lines.

True, but what is said is:

  We continue to invest in tools to improve the safety of our C/C++. Over the past few releases we’ve introduced the Scudo hardened allocator, HWASAN, GWP-ASAN, and KFENCE on production Android devices. We’ve also increased our fuzzing coverage on our existing code base. Vulnerabilities found using these tools contributed both to prevention of vulnerabilities in new code as well as vulnerabilities found in old code that are included in the above evaluation. These are important tools, and critically important for our C/C++ code. However, these alone do not account for the large shift in vulnerabilities that we’re seeing, and other projects that have deployed these technologies have not seen a major shift in their vulnerability composition. We believe Android’s ongoing shift from memory-unsafe to memory-safe languages is a major factor.

They "believe" the major shift is due to Rust, while they continously improve also their C++ tools, and the count in also all violations (even mabe more theoretical ones?) found by those .. I have no doubts about the actual claim, but especially this quite sounds like they may have made more out of this correlation==causation than there maybe is, I believe ;)

I know some of the people who own the tools described above. I can assure you that if those tools were the primary cause of the reduction in vuln they'd be screaming it from the hilltops. A huge amount of work at Google goes into answering questions like "what actually accounts for this change." This is one of the benefits of the promo culture that is often criticized.

Programming languages are tools for a job. As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously, whether it's Google or not.

Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them.

Of course, there are languages that abstract memory safety to the point that they eliminate those types of mistakes. But languages are tools for a job, and only some tools are applicable where C++ is applicable. We should not bury C++ prematurely before answering the question - "what else is as fast and efficient as to replace it for OOP?" And if a project doesn't need fast and efficient code, then why is it using C or C++ in the first place?

Overall, selecting the correct tool for a job is more important than figuring out which tool is better in some abstract way.

Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them.

This recapitulates an argument at least as old as C89. You can probably find Usenet posts deploying it to argue against the adoption of strncpy, because if people don't know how to use sizeof and strlen, then bad for them.

strncpy is bad for other reasons, mind you.

Yes, my argument sounds similar. But it's in support of modernity rather than primitivism.

C++ nowadays can be used in a very memory-safe way without much effort. In my professional experience, memory leaks and corruptions are sporadic in modern C++ code and common in old-style pre-C++ 11 code.

That's why I'm a bit skeptical of this article from Google. It seems reasonable that Android has quite a lot of pre-C++ 11 code. And the article seems to lump two very different approaches to memory safety in pre and post-C++ 11 style programming.

You can do some basic analysis about your assumption: go pick out a bunch of the CVEs and look at the age and style of the source code.

Another approximation is to look at the Android source tree to see what proportion of it is as old as you assume in your argument. There are 431 results for a search `"Copyright 200" filepath:.\.cpp`. There are 7465 results for `"Copyright 201" filepath:.\.cpp`. 4152 results for `"Copyright 202" filepath:.\.cpp`. 220 for 2012, 354 for 2011. If you exclude tests the ratio is even less favorable for your theory.

In case you're wondering the project policy is to add a copyright header at the time the file is created, they do not update years in headers arbitrarily. As a spot check the first file matching "Copyright 200" that wasn't just essentially C code wrapped in extern "C" was: external/angle/src/libANGLE/Config.cpp. This file contains the use of std::make_pair.

You can perform these searches yourself here: https://cs.android.com/search?q=%22Copyright%20200%22%20file...

Thanks, that was very insightful. Yes, as you say, the copyright year in a .cpp/.h doesn't necessarily say whether C++ 11 features are used.

I've looked at many "Copyright 201" and "Copyright 202" headers. I needed to see more use of C++ 11 or equivalent smart pointers or containers to say that this codebase uses modern C++ memory safety features. Other modern C++ features (like std::make_pair that you mention) are easier to spot.

I expect this codebase to have many memory safety issues. It may not pass code review in a company/team that expects their people to use modern C++ memory safety features. After seeing it, I'm more convinced that the reason Google has so many problems with C++ in Android really is because they don't insist their engineers use modern C++ (or equivalent in-house containers/pointers).

Here's another insightful pair of searches:

" std::make_" filepath:.*\.cpp

"delete " filepath:.*\.cpp

I mentioned this elsewhere, but the real A/B test here would be to do a rewrite in the existing language and compare it to doing a rewrite in Rust with respect to memory safety, etc.

"std::make_" isn't a great comparison (IMO) because Google has a widespread culture of noexcept so it wasn't critical to adopt this style for constructing smart pointers. std::unique_ptr<Foo>(new Foo()) was a thing for a while there. There is also an alternative absl::MakeUnique<T> that was available before we had std::make_unique available internally so you'll need to search for that too.

The style guide, C++ readability, and general code review has all but banned raw "new" for years and years. You can find plenty of CVEs where the root cause is a UAF on a managed object.

Yes, there are more examples of smart pointer initialization than just std::make_. I couldn't find instances of "absl::Make" in Android Code Search. But your point still stands, and I should add that not all new-delete pairs are evil. With that said, what I've seen still has too many raw pointers.

Thanks for the context about UAF. I am curious about this. Much of my C++ experience comes from working with in-house reimplementations of std/stl, so my question might be a bit stupid, but how is use after freed of an obj managed by smart pointers so prevalent? Should the smart pointer not be nulled after the object is destroyed? Maybe you have a good example CVE? Are these cases of using the raw pointer in the smart pointer without checking it first?

> Should the smart pointer not be nulled after the object is destroyed?

I'm not sure what you are going for here.

The way this often happens is there is some module that owns an object with a unique_ptr and references to that object are used elsewhere. But the ownership of the object is complicated so a bug sneaks in where a non-owning reference to the object gets dereferenced after the unique_ptr is deleted. You can prevent this by having literally everything use shared_ptr for everything but that sucks for lots of reasons.

There are also other smart pointers, like std::'s weak ptr and proprietary stuff.

You can avoid multi-ownership problems of shared ptrs with weak pointer member variables (which only need to be turned into shared in a given {} scope). Some other problems can be solved by marking objects as pending kill without destroying them immediately and ensuring all threads finish access before actual deletion.

Unreal Engine uses both weak pointers and object marking in a global object array. It also uses GC but that's besides the point.

Would the same approach to modern memory management not help Android?

Of course there are designs that help prevent bugs. Chrome is doing plenty of stuff like this but the ownership and lifetime design for something like a JIT are complex as hell and problems happen.

We've got like 30 years of people insisting that it really is possible to write safe C and C++ programs if you just follow the One True Way (TM) and its never been the case. Each new One True Way helps, but it sure as hell doesn't solve the problem altogether.

strncpy doesn't do what you want. Maybe you mean snprintf. Indeed use of sizeof, memcpy, and snprintf. Avoid strlen, it is rarely necessary.

A bad workman may blame his tools, but a good workman uses the right tool for the job. If a better tool exists, use it.

(And sure, it doesn't apply to every niche yet, but it sure applies to a lot of them)

> As the saying goes, a bad workman blames his tools.

And a good workman put his old/obsolete/dangerous/etc tool behind when something better show up.

The bad workman, instead, continue blaming his tools, when the problem is that he CONTINUE using bad tools, anyway!.

P.D: I learn about mechanical engineering. Get rid of bad tools fast is like key around that...

First rule of tool buying, never buy the cheapest for the safety-related tools. C/C++ IS the cheapest

> As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously

Are you serious? A bad workman blames his tools, because workmen are reponsible for their tools. A large part of being a good workman is identifying what tools are good and using them.

And C++ is a terrible tool for any task where you are not forced to use it because of existing libraries. All the memory safety features of modern C++ are a tiny, almost vanishingly small step in the right direction.

> "what else is as fast and efficient as to replace it for OOP?" And if a project doesn't need fast and efficient code, then why is it using C or C++ in the first place?

If you need fast and efficient code, why on earth would you be doing OOP?

> A bad workman blames his tools, because workmen are reponsible for their tools. A large part of being a good workman is identifying what tools are good and using them.

As I said in the comment to which you are responding, "selecting the correct tool for a job is more important than figuring out which tool is better in some abstract way."

> C++ is a terrible tool for any task where you are not forced to use it

Many game developers, OS developers, and massive hardware-software makers doing embedded programming who use C++ would disagree. What would you say to them?

> If you need fast and efficient code, why on earth would you be doing OOP?

For small projects, I could agree. What would your recommended alternative be for massive codebases in large tech companies that need fast and efficient code?

P.S. Please read https://news.ycombinator.com/newsguidelines.html about snarky comments. Thanks.

> For small projects, I could agree. What would your recommended alternative be for massive codebases in large tech companies that need fast and efficient code?

The poster wrote very clearly:

> where you are not forced to use it

If one is forced, there's obviously no option.

The idea is not that C/C++ should be replaced right now, rather, that devs finally understand that C/C++ should not be used where possible.

I actually see this pattern used by some, who defend C/++: "C/++" should be deprecated" - "No, it's impossible to eliminate C/++ today".

Deprecation is not elimination. Linux started introducing it, and Google is doing as well, so it can be done gradually.

>> As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously

>Are you serious? A bad workman blames his tools, because workmen are reponsible for their tools. A large part of being a good workman is identifying what tools are good and using them.

Also C/C++ made into real life tools would be OHSA violation on OHSA violation in real world

> We should not bury C++ prematurely before answering the question - "what else is as fast and efficient as to replace it for OOP?"

We have an answer: Rust. It's no longer premature, bury it.

Amen.

Rust is over engineered in some area, immature in other.

See how many reference types are there, how async is handled and the underspecified unsafe semantic.

For higher level tasks, I prefer a language with GC like go or java. Rust can work with references counting, but it don’t mix well with the larger ecosystem. For lower level task, the underspecified unsafe model make it worse than C aliasing problem

> See how many reference types are there,

2, & and &mut. What else?

I guess parent meant ARC, RC, and the like.

I vastly prefer "just write you code serially and never worry about async then spawn 10000 goroutines" approach over async/await/Future nexus of bad ideas (just do message passing like Erlang or don't do it at all...), but I wouldn't use Go in place where I'd use Rust and vice versa, they kinda feel different (if overlapping in places) niche

It is very freeing. And one concise readable go routine doing the channel reads and the socket ops becomes your connection pool, but is as easy to understand as a Network programming 101 assignment.

How's Rust at doing OOP these days? (Assuming we're in a domain or situation where OOP is a good choice, of course.)

I would love to know about any projects that do OOP well in Rust.

IMO Rust has most of the best bits of OOP (the ability to encapsulate functionality in an object with private fields and present a restricted public interface), without the bad bits (inheritance, and complex soups of objects all holding pointers to each other that make code flow hard to reason about)

Rust isn't OOP though. Structs, traits, etc. let you approximate some aspects of OOP, but not much more than plain old C does.

Languages encourage or prevent its users from doing things

Concepts like sugar syntax and syntax salt do exist

Approaches to problems may vary by languages because lang environment shapes its users in some ways

>If they’re saying that C++ can’t be saved, maybe they’re worth listening to.

Google's one of the worst C++ shops because their code standard basically forbids using modern C++, and their C++ is more like 90s Java than modern C++. It's no wonder they want to get away from it.

I...what?

I write C++ at Google, and it encourages use of modern C++ features, and many things you see adopted in std have roots in our libraries.

I'm curious what you think Google prevents us from using and why you think our C++ is like 90s Java.

https://abseil.io/tips has a lot of our philosophies and abseil is chunks of our internal libraries published externally.

I've weirdly heard people say this in the past too and I am equally baffled.

I think it stems from the fact that Google was slow at making C++11 available internally so there was a period of time where the rest of the world was using smart pointers and we couldn't. That may have just solidified a "Google uses old C++" meme out in the wild despite it being wildly out of date.

Google’s C++ coding guide is (was?) not really up-to-date, so there is that.

Modern C++ is indeed a huge upgrade on what came before and with a good amount of static and dynamic analysis the state of low-level programming is much better now, but there really is no reason for new programs to be written with these. Besides the bottom of the stack, managed languages are more than fast enough for nigh everything.

> Besides the bottom of the stack, managed languages are more than fast enough for nigh everything

And yet, there is a lot of enthusiasm (at least here on HN) for web development in Rust...

There are plenty of people who want to write in Rust for the fun of it. But I'm not aware of too many people saying that you should avoid writing a web application in java/python/js in favor of rust. Pretty much the only people being told to stop doing what they are doing are the people starting new projects that process untrusted data in C and C++.

You and your parent are saying slightly different things with regards to web dev; they said there's enthusiasm for doing it, not that you shouldn't write web applications in those languages.

Someone can think it's fine to write a web application in java/python/js and Rust.

Never mind you don’t give up any performance to use Rust anyway. They focused heavily on only incorporating features with zero cost abstractions.

Google is great at engineering projects that look great in promotion packets. Just because they're big and funded doesn't mean they're good at this.

It seems plausible that splashy projects in new languages are better for careers than grinding through "stable" codebases using "boring" engineering practices.

I also gather that Google has a challenge, possibly for similar reasons, keeping their third party dependencies updated and up to standards. A lot of those are written in C and C++, probably.

//third_party is indeed a challenge, but it is definitely not the case that vulns are only coming from //third_party. I mean, the linked article is about the Android codebase (not attached to //third_party) and the Chrome codebase publishes a ton of vuln data (again, not attached to //third_party).

I was saying Google might be pessimistic about C and C++ for some reasons specific to Google culture, like inability to get engineers to care about "boring" work. I wasn't making the point you're addressing.

I assure you that "fix vulns caused by memory safety issues through some means other than a total language shift" is not boring work, but the sort of problem that will happily get people promoted to L8. It is just hard as hell.

One of the people most involved in the systems described in the blog post that are used to harden the C++ side of things is a L9 here.

I more meant the mid range engineer work to just buckle down, test, and fix things. As in, just owning and cleaning up a lot of important projects, including third party ones.

Designing the ultimate everything sanitizer with zero performance overhead would surely be impressive even at Google. Especially if it was actually adopted across the org.

But "buckle down and own it" doesn't actually prevent vulns in any sort of systematic way.

And I assure you that, despite the memes, code health efforts do end up with promos here. The org responsible for third_party and large scale code health had above average promo rates for ages.

While new safety features in C++ may be impressive, Google's data shows that memory safety vulnerabilities are still a major issue. Switching to a memory-safe language like Rust can help reduce the risk of vulnerabilities and improve the overall security and reliability of a product. The potential benefits make it a worthwhile investment, even if it requires some effort to migrate from C++. #RustIsTheRealDeal

How much of the benefit comes from the rewrite itself? A more precise comparison would be rewriting that C or C++ in the same language but with memory safety in mind and see how things turned out.

The same question comes up when an existing system is rewritten from language A to language B and big performance gains are seen. The language could be the big cause, but so could the extra engineering effort itself -- updated design, fresh attention to the requirements, etc.

Google isn't rewriting more now than they were before, they're just discussing the use of C/C++ for new code. Presumably, if rewriting chunks of code were enough in its own right, they would never have had so many critical security flaws.

I also agree that it's a presumption. I don't know that I agree with it is all. It seems like more engineering attention and excitement is actually good for project quality, and maybe that's a confounding factor here. More data would help, though all this might never be definitively conclusive.

> if rewriting chunks of code were enough in its own right, they would never have had so many critical security flaws.

Reducing defects is one of the main reasons (others being maintainability, readability, better integration, and similar) for refactoring and rewriting code. There's usually not enough time/money to do it, especially for large codebases.

I quite like rewriting parts of a codebase to modernize it, and I have often closed tons of bugs in a short time this way. It is definitely effective. But not as cost-effective as deprioritizing bugs into "won't fix" territory, which is what many companies like to do.

And yet, people still store a string_view in a field and then access it past the lifetime of the underlying string.

Yes, things have gotten better. Smart pointers are a godsend. Sanitizers are a godsend. Various static analysis tools work pretty well.

But even codebases that adopt all of these things religiously still are riddled with security vulns.

Reply on news.ycombinator.com