Bjarne Stroustrup: Think seriously about “safety”... [pdf] | Hacker News Reader

Bjarne Stroustrup: Think seriously about “safety”... [pdf]

open-std.org

58 pointspjmlp143 comments

>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...

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.

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...

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.

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.

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.

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.

Not much to see here. Just the C++ community sticking their collective heads in the sand about memory bugs, as they are wont to do.

(Yes, C++ core guidelines exist but they are complicated and don't guarantee safety in many cases.)

Those are practically a joke. "Don't dereference a possibly invalid pointer". Thanks, Bjarne. That hadn't crossed my mind, but I can imagine why you would write that. The language simply can't stop it.

These, on the other hand: "Don't return a T&&", "Don't use a variable for two unrelated purposes" (in the context provided), "Don't define a (C-style) variadic function" and many others can be excluded from the language. Yes, you can forbid reusing loop variables. It's in your hands, Bjarne. Remove these constructions from C++.

But why remove them? What's wrong with declaring int i at the top of your function (like old-style C) and then using it throughout all loops in the function?

You can't just cull old variadic functions because some old stuff won't work. It's easy to say "just get rid of it!" but that's never going to happen because it's backwards compatible. People really should be using parameter packs now instead of old variadics but I have worked with "developers" who hadn't a clue about them. The senior developers dismissed the new features as syntactic sugar and insisted on writing old-style code. They detested std::pair. They were unaware of move semantics. An rvalue reference was unknown. Lambdas were pointless to them.

It also isn't in Bjarne's hands - it's the committee. He fought against various things (as I recall from his talks at cppcon) but they ended up in the language anyway.

> What's wrong with declaring int i at the top of your function (like old-style C) and then using it throughout all loops in the function?

Ask Stroustrup. It's his example, and in this case avoidable.

> You can't just cull old variadic functions because some old stuff won't work.

Yes, you can. They've removed quite a few features from older C++ versions. You can turn them back on, if you want. So for C++x24 or whatever, they could say: for loop variables are always local, C variadic is no longer permitted, etc., and use some compiler flag to re-enable it.

> It also isn't in Bjarne's hands

But that's probably the person with most influence on the language. And if he would propose a C++safer version, which deviates from the standard by eliminating as many bad practices as he sees fit, people would follow, and the two would probably merge at some point.

But that won't happen, which makes the core guidelines a bit of a joke. "Here's an apple. Don't eat it."

Good points. I myself would be happy to see va_args disappear but it'd require work from the maintainers of the compilers etc. which is unlikely to get support, I guess?

I especially love that piece of guidance because there isn't a good way of testing whether a pointer is invalid.

Imagine I'm a function and I've got a pointer to some object. I know the object is owned by something else. Let's say I want to be extra safe and check whether the pointer is valid before accessing it. How do I do this? I cannot dereference it. I can't compare it against something useful. I could have a custom allocator that tracks the status of all allocated and freed regions of memory, cast my pointer to a void pointer, and check with the allocator (I think this isn't UB). But now I've also got to make sure that freed regions of memory are never reused for any reason. Thanks Bjarne.

But a bug is just a bug, regardless of the system it involves (memory, disk, network). It isn't the fault of the language that bugs get written by developers, in the same way that it isn't the fault of the car that people crash them.

You seem to be proposing that there's some magical bug-less language we should be using instead?

> And anyway, what is “the overarching software community”?

I feel that it's pretty much a consensus in the software security world that C and C++ should be avoided. Not sure why he omitted Rust from the list, it is in the original document, and is pretty much a drop-in replacement for C++. Also using a dynamic language like Ruby for anything secure or safe sounds like a terrible idea.

Can you please expand on

> Also using a dynamic language like Ruby for anything secure or safe sounds like a terrible idea

afaik, it depends on how you use Ruby right? I agree that using metaprogramming could lead to issues, but i would like to hear your view points on security?

I assume this is because the number of properties that can be statically audited in Ruby (or in most dynamic programming languages) is extremely small wrt what you can do in strongly-typed programming languages such as Rust, Ada, Haskell, OCaml, F#, ...

Static audits (including, but not limited to static typing) are very strong barriers against entire classes of safety issues. Not supporting them doesn't automatically make code bad, but it prevents lots of defense-in-depth (what the Rust community calls "fearless programming").

Unfortunately, there are a lot of overloaded terms.

Languages like Ruby are indeed nightmares for static analysis. Even constructing a call graph is a disaster. But "safety properties" includes a huge amount of stuff that isn't necessarily security relevant. Do you want to prove that your Ruby program won't crash? Good luck. But do you want to prove that your Ruby program won't read key material out of memory when it shouldn't? Pretty easy. The security problems in these sorts of managed languages tend to either be logical errors (also present in a C++ codebase) or dynamic code loading / unsafe deserialization (not present often in C++ codebases, but much easier to eliminate in principle).

For what it's worth, I am not attempting to compare Ruby (or generally dynamic languages) to C++. I am comparing Ruby to statically, strongly-typed languages. C++ is statically typed but is generally not a strongly-typed language, since there are many ways to escape strong typing, either willingly (e.g. with a cast to `void*`) or by accident (e.g. through UB).

> But "safety properties" includes a huge amount of stuff that isn't necessarily security relevant.

Good remark.

However, as a former safety (not security) researcher, it feels to me like the consensus in some parts of the security community is that once you have lost safety guarantees (i.e. you're not sure what your program is going to do), you have lost this entire line of defense and need to move to the next one (e.g. containerization).

Example: Python has a very clear syntax and it is often easy to audit code to find out whether the algorithm implemented matches the specifications. However, Python is also a language in which `True`, `False` or integer literals can be redefined dynamically. So, with this in mind, how can you be sure that your Python code that appears to calculate fibonacci is not going to actually `ctype` into something memory-unsafe that could be used to escape into the shell?

Of course, this example (and anything analogous in other dynamic languages) requires active malicious intent by the author of the code or one of the module it uses, but it's not too hard to come up with examples that end up with OS or XSS injections, without malicious intent by the code author.

I believe that we both agree that these examples are safety issues escalating into security issues.*

That part was a quote from the NSA. He didn't omit it. But I agree his argument would have been stronger if added to the list the most realistic C++ competitors and differentiated against those instead of the more dynamic languages.

Looks like there are two lists in the linked document - one of them includes Rust and the other doesn't. My bad.

The quoted document has two similar sentences, one on page 3 includes Rust, one on page 5 does not:

> Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®.

> Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®.

https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...

Stroustrup quotes the second one without Rust.

Rust is definitely not a drop-in for C++, be it for interop with massive C++ codebases or developer adoption. You may be able to get your devs to switch, but your productivity will suffer so much that your stakeholders will be on your ass to figure out how to fix something there is no fix for: the mental load of Rust is a lot higher than C++'s and it takes a long time for regular people to become as proficient in it as they are having written C++ for 15 years.

> the mental load of Rust is a lot higher than C++'s

I don't believe this. That's a reasonable claim for many other languages, but C/C++ are in a category of their own.

>"C/C++ are in a category of their own."

If one wants to know it all then yes. C++ is huge language. In practice except few people nobody really needs to. Subset of modern C++ enough to solve many real world tasks is very easy to learn in my opinion.

With Rust one must first train brain to wrap around those ownership rules and this might not be easy.

Fortunately or not I do not know even remotely enough of Rust to do the real comparison of "mental load" but at some point I will.

> With Rust one must first train brain to wrap around those ownership rules and this might not be easy.

You need to do that in c++ also, otherwise you'll still have the same problem - only randomly at runtime instead of at compile time.

>With Rust one must first train brain to wrap around those ownership rules and this might not be easy.

C++ users already understand ownership because C++ has ownership too. With C++ you have to me extra careful because the compiler won't save you from making mistakes like Rust will.

I meant ownership as implemented in Rust. I am perfectly fine with ownership models of C++ and some other languages.

>I meant ownership as implemented in Rust.

It's the same thing in Rust and C++. There is no difference conceptually.

Disagree, unless we're including Rust's unsafe. Excluding that, you need to understand what the Rust compiler is able to prove is safe. In C++, you "just" need to prove to yourself that it's safe. It's a very different experience writing code.

So perhaps "ownership rules" is the wrong vocable for this. Maybe "ownership proofs"?

In Rust you need to understand borrowing to write programs that compile. In C++ you need to understand borrowing to avoid writing programs that use undefined behaviour.

Yes, it's a different experience, but both have the same concept of borrowing that you must understand.

It's the opposite of my experience. The mental load of Rust is lower than C++ because I can trust the compiler to take care of and track ownership and lifetimes, whereas with C++ that has to be done manually.

And yes, I aware of all the bells and whistles modern c++ can bring to alleviate some of that burden - but people can and do subvert those mechanisms intentionally and unintentionally, especially over refactors.

By bells and whistles, do you mean smart pointers that have been around for decades and destructors?

I have a codebase that I ported from C# to C++ and found a few bugs where the items were copied instead of moved. In C# this was completely invisible since I "trusted" the compiler to do it properly - it did it wrong according to my wishes but right compared to the language.

By contrast in C++ it was very visible when the ownership was shared and wrong. I would rather use C++ because of this rather than trusting the compiler to get it right.

The same was true on generics/templates for a function/parameter system I'd written. The C# compiler resolved to the wrong function every single time but in C++ it resolved correctly.

I suspect there are plenty of subtleties in "safe" languages that actually muddy concepts of owernship and/or needless copying and lifetimes.

> I suspect there are plenty of subtleties in "safe" languages that actually muddy concepts of owernship and/or needless copying and lifetimes.

True in my experience. However, not the case in Rust, which is actually much more explicit about ownership, copying and lifetimes than C++.

Very interesting. I will read more. Thanks!

>where the items were copied instead of moved.

Uh? What was being done there?

> the mental load of Rust is a lot higher than C++'s and it takes a long time for regular people to become as proficient in it as they are having written C++ for 15 years

There are very good reasons to use C++ rather than Rust for some projects, typically interoperability, or developer already having experience in C++, as you mention.

However, having coded in both C++ and Rust professionally, my experience is that switching Rust has liberated much of my brainpower to concentrate on actually implementing useful stuff, so I have to strongly disagree on "mental load".

What is true is that, for a while after switching, getting code to compile in C++ is easier than in Rust. Took me maybe 6 months to 1 year before it became natural? However, as we all know, there is a huge difference between writing code that builds and writing code that works. In my experience, that difference is order of magnitudes larger in C++ than in Rust.

Personally I found Rust much easier to learn than C++

As someone who developed professionally in both C++ and Rust, I found it that it was much faster for me to believe that I had learnt C++ :)

> Not sure why he omitted Rust from the list, it is in the original document

Nice observation, that seems to change the meaning of the paper substantially. OP might be privately admitting that you should use Rust if you can (not much that's new here, the Carbon folks said the same thing) and everything else just silently assumes that you can't do that for some reason - be it legacy or perhaps concerns about Rust's supposedly challenging learning curve. (It goes without saying that we shouldn't expect a C/C++ committee paper to outright advocate for Rust.)

>"Rust ... is pretty much a drop-in replacement for C++"

Performance and "low-levelness" wise it most likely is. From high level point of view it messes with how one must think when writing code and is missing some features / paradigms found in modern C++ (for better or worse, not gonna dwell on it here).

In my opinion it is closer to "drop-in replacement" for C.

I mean modulo interop with legacy code or need for proprietary compilers Rust can be used wherever C++ is used. Not quite true for C#, Go etc.

> Not sure why he omitted Rust from the list, it is in the original document

He didn't remove Rust from the quote though. The NSA document[1] contains two lists of languages considered safe and for some reasons Rust is only included in one:

> Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®.

> Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®

[1] https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...

We’re not ignoring 30 years of improvements, they’re just irrelevant because the statistics show that they are.

Sure write some more planned improvements, double down, that’s fine, but if you’re presented with the kind of history and data we’re looking at, would you bet on them?

The performance topic is hyperbole. We’re not talking about bounds checking - that topic is irrelevant and has well understood solutions in written systems. There are swaths of code now demonstrating direct competition in large practical systems and small benchmarks. Lots. The performance argument is so unsubstantiated it’s almost dishonest.

There’s an implication buried in here that there is some set of problems that only c++ can solve. I’d like to see those written down in a focused manner, just the problem and it’s c++ solution. We can take it from there to see if the problems are truly unsolvable with any other tool.

> There’s an implication buried in here that there is some set of problems that only c++ can solve.

Not sure about that. But the c/c++ community is still larger than, e.g. rust hence some worthwhile innovations (most recently e.g. co-routines, also executor interfaces for accelerated compute) show up first in c/c++. Then hopefully the rust folks figure out how to expose them to developers in a safe way.

what is new about coroutines or executor interfaces?

For context, both C, C++ and Rust have had experimental implementations coroutines for ages.

They're not standardized in C and Rust. And in C++, the only feedback I've seen is https://probablydance.com/2021/10/31/c-coroutines-do-not-spa..., which didn't look very good.

Other languages have already figured that out.

C++ currently still needs to figure out its executor's story, as so far it also needs to depend on third party implementations.

I can attest that C++/WinRT story is quite painful, unless one is really deep down into co-routines and how they might interact with various COM/WinRT process models.

See The Old New Thing blog about them.

He doesnt like NSA calling C CPP unsafe cuz CPP is way safer than C and the fact that lang committee wasnt asked about their assessment. Then he recommends reading CPP safety guidelines and links some CPP proposals to make lang better. Also reminds that there various kinds of safety and trade offs.

I think guidelines are poor ass method to improve security, especially when you can see that projects like Chromium still have a lot of mem. related safety.

Yeah, that gripe about the C++ standards committee not being consulted is a bit petty. It's likely the NSA didn't consult ~any language maintainers; there is plenty of error rate data coming out of large corporations to go on.

> projects like Chromium still have a lot of mem. related safety.

Chrome might suffer from being a Google project. At least the old Google C++ style guides heavily pushed a C with classes approach and where outright hostile to every improvement over C new versions of the language brought along.

My guess is the reason is C++ is complicated.

When you have restrictive conventions, it is easier for a new dev to get onboard, as well as for creating static analysis tools.

Google C++ forbids exceptions, but C++ RAII works a lot better when a data member ctor can throw. The compiler will generate code tearing down a half-constructed object from that point, without you having to write a method that knows what to do and what not to.

What percentage of CVEs in Chromium are caused by half-complete objects where a constructor throw would have prevented the issue? I certainly don't have an exhaustive view of things but no example is coming to mind right now. With [[noexcept]] everywhere I'd expect a constructor failing to just crash Chrome rather than proceed in some indeterminate state.

https://google.github.io/styleguide/cppguide.html#Exceptions calls for factories or init methods (probably returning error codes) so running with an invalid state isn’t prevented by terminating the process.

I don’t have access to CVEs on crbug.com but the top two from https://chromereleases.googleblog.com/2023/01/stable-channel... are a use-after-free and buffer overflow reported months ago, which is the kind of stuff that modern C++ tries to avoid using containers and smart pointers with RAII.

Of course modern C++ tries to avoid this sort of thing now with smarter lifetime management, but what does that have to do with building with exceptions disabled?

I think they use their own containers and smart pointers which require explicit initialization (more scope for mistakes), to avoid standard C++ classes whose copy/move ctors can throw.

If you have to think about safety then the technology is unsafe by default, ergo not suitable for security and reliability critical systems. No amount of thinking is going to fix that.

I haven't built anything out of choice in a C derivative since the late 1980s, unless I explicitly wanted to break something or do something naughty or talk to hardware directly.

Knives are dangerous. We shouldn't use them in houses...

If you want to use a knife analogy, we're using C for prying things open, sawing up timber and opening locks. There are better tools for those jobs that don't end up in blood loss and misery.

That'll explain my failures in all DIY jobs around the house then!

You use many tools in a house. Most are designed with implicit safety measures. You should use knives for specific tasks that warrant the use of a knife. You should not run around a house knife in hand using it for everything.

Inb4 this thread gets carcinized -

While it does sound like Bjarne is being a bit of a sore loser of some popularity contest, he's still right in that exactly memory safety is too specific of an idea to be meaningful in the long term. Personally, I love arbitrary memory access. I can have a Julia server running in linux, expose a pointer address to stdout, pipe it to an SDL renderer, and the whole time be confident in my ability to make it work because it's C all the way down. If these languages were half as anal as say Java about their ideology I'd be downright insulted to use them at all.

C++ is interesting because it's really anal about its semantics, which turns into a sort of anti-ideology. There's comfort in not knowing what the big picture is when the language itself also has no clue, but lets you do whatever you want anyway. The mental weight of having to track lifetimes is just exercise.

Ultimately I think there are attackers and defenders. People who don't mind getting shot and people who do. Why is Bjarne worried about what the defense has to say about him? The N.S.A. (ffs) is simply playing a way different game than, dunno, arch, clang, llvm, Forth, Mathematica, whatever. It doesn't really matter.

Memory safety is not "too specific", it's table stakes if you want any kind of logically sound semantics. If you care about logical bugs in a broader sense, you should care about safety.

> If you care about logical bugs in a broader sense, you should care about safety.

Case in point, ideology. I guess I don't care about bugs as much as I care about product? And I don't really have to, it's not like I get paid for this.

Time spent abstracting data iterators >>> time spent memorizing warning flags

> Personally, I love arbitrary memory access.

C++ does not really permit this. It is incredibly hard to do type punning from void* without hitting UB. You really are only allowed to access objects through their names according to their lifetimes.

Here (https://www.youtube.com/watch?v=IAdLwUXRUvg) is a fun talk that involves trying to do a pretty basic kind of arbitrary memory access and concluding that it is simply not possible in C++.

From my understanding C is really nonchalant about this. The resistance is mostly from the OS side.

I'm sure with C++ it's more complicated, but not impossible. With Rust it gets really funny. You have to subscribe to a completely unrelated mental model to read some numbers from a tape.

C is more nonchalant. Since the thread topic is C++, I thought it was relevant.

They say C++ is C + STL. Then C is what, C++'s printf?

Sorry

What?

Too late! It's RUST EVANGELISM STRIKEFORCE in all it's knee-high pastel-stripe socked glory!

Ruby uses C underneath, so if there is an implementation issue of how C is used to implement a feature in Ruby, it could still lead to issues.

But most of the ruby language is tested at trunk by the big companies like shopify, github etc to patch any issues.

I largely agree with this though: > even “safe” code (in any language) will have to call traditional C or C++ code or be called by traditional code that does not offer specific safety guarantees.

Shopify is reducing their dependency on C, including for Ruby tooling.

https://shopify.engineering/shopify-rust-systems-programming

https://shopify.engineering/porting-yjit-ruby-compiler-to-ru...

TIL. The second link is pretty interesting, may be one day it could become the default for ruby if the core team agrees with the reasons mentioned there.

C++ and the compilers did a lot for safety in recent years:

    * smart_ptr
    * RIAA
    * Address-Sanitizer

But C++ allows for legacy code compatibility (a strength) but at the same time we don't have a compiler switch like "unsafe" and operator[] without bounds-checking (a weakness). I want it like in Rust, default mode is "safe" and the option to be "unsafe" when necessary. Is it late? Yes. Is it to late? Never. I want the compiler to tell me "You're doing dangerous stuff. Sure?".

Interestingly they don't mention Rust. Java and C# are designed for completely different usages.

Normally I don't comment on typos, but RIAA instead of RAII is a pretty funny one.

Which illuminates the real problem of RAII (that instead all Resource Initialization is Acquisition.) You often need to explicitly control the order and timing of the initialization of various resources. But RAII often gives away control of that and either becomes a source of bugs or makes your code more complicated when working around it. Separate init() methods are not the devil, there’s a reason for using them… (if you’ve ever tried writing and failing to create an object-oriented wrapper of a graphics API like OpenGL you’ll know what I mean.)

RAII is good enough for automatically managing some simple parts of your data structures (some auto-freed vectors and strings are convenient), but it becomes haywire when you’re using it to manage more complex data structures, or something other than conventional memory (Like GPU buffers, handles from external systems like the OS, etc…) Single ownership of data can be too much of an ideal in reality, and shared_ptr semantics can be undesirable for expressing shared ownership in many scenarios.

I don't like Init methods because they permit the creation of invalid objects. Instead, either throw an exception from the ctor or use a factory function that can either return a T or an error.

I'm curious what weaknesses of shared_ptr you've found. With the addition of weak_ptr and enable_shared_from_this, they're a pretty versatile tool.

Throwing exceptions might not be acceptable in your use-case, with many codebases disabling it for concerns of performance or executable bloat. And factory functions cannot really help the initialization problem anyway, since your field is still in an uninitialized state before calling the factory function. And also, returning std::optional or std::expected can sometimes lead to slower code (copy constructor being called) because of NRVO not working when the compiler “feels like it”. So an init() method/function that returns an error code is the best you can get.

I think the best way to really solve the invalid object problem in C++, is to always put sensible default values inside your struct/class definitions, so your code will at least fail without UB (in addition to using asserts liberally to check for index overflow problems, especially in your own containers even in. Release mode.) Zero-initialization is good for most cases, but sometimes you might need to default-initialize your indices to -1.

weak_ptr is really slow, because of the lock instruction generated for each lock(), as well as the added indirection cost. Once you use them all over the place to fix reference cycles, the overhead of using these becomes hard to ignore. Generational indices/references remove all the ref-counting and gives programmers the semantics of weak_ptr without the performance cost (see https://verdagon.dev/blog/generational-references, the details are mostly language-agnostic).

Not sure safety can be improved with new guidelines of how to avoid common safety pitfalls.

Old man yelling at clouds because the trees called his C dialect from the 80s unsafe and recommended Java, C#, Swift, Ruby or Go instead, which is a great injustice to his C dialect.

Reply on news.ycombinator.com