Memory Safety for Skeptics

https://queue.acm.org/detail.cfm?id=3773095

by steveklabnik • 8 months ago

89 198 8 months ago

queue.acm.org

whobre• 8 months ago

Ugh. I know all that and I am still sick of hearing about memory safety. My teammates spend way more time fixing security issues in “safe” languages than C/C++/whatever. It simply doesn’t matter…

kazinator6• 8 months ago

It's hard to compare the two. A low-level memory safety issue can intersect with security. So can a flaw in logic that touches on security, but is reproducible and not undefined in any way.

The latter can often be more easily exploited than the former, but the former can remain undetected longer, affect more components and installations, and be harder to reproduce in order to identify and resolve.

As an exmaple of "more easily exploited". Say that you have a web application that generates session cookies that are easy to forge, leading to session hijack. Not much skill is needed to do that, compared to exploiting a memory safety problem (particuarly if the platform has some layers defenses against it: scrambled address space, non-executable stacks, and whatnot).

mrkeen2• 8 months ago

What security issues are biting you in safe languages that wouldn't also appear in C/C++ ?

quotemstr3• 8 months ago

Perhaps he's talking about risk compensation (https://en.wikipedia.org/wiki/Risk_compensation) --- e.g. maybe safe languages structurally excluding memory corruption and concurrency problems tempts developers to let their guard down with respect to correctness generally and produce security vulnerabilities that wouldn't occur in a language with C's need for rigor.

Doubtlessly, there is some of that going on. I doubt the risk compensation erases the benefit of memory safety, but let's not kid ourselves.

bluGill3• 8 months ago

A large number of real world security issues are attacks on humans not software. No programming language can solve social engineering problems.

kazinator6• 8 months ago

If you're tired of hearing about memory safety, this article is for you.

Tell me more about memory safety, any time; just hold the Rust.

Rust skeptics are not memory safety skeptics. Hopefully, there are no memory safety skeptics, other than rhetorical strawmen.

Yoric6• 8 months ago

I've spoken with quite a few C++ developers who swear that they don't need memory safety tooling because they're good enough to achieve it on their own. More than a few also expect that the worst that can happen from breaking memory safety is a SEGFAULT, which also suggests that they don't understand memory safety.

So, I'd say that there is still some outreach to do on the topic.

On the other hand, you're absolutely right that Rust is only one of the many ways to get there.

kazinator6• 8 months ago

OK, so those are skeptics about tooling, not about memory safety per se.

And not even about tooling per se, since achieving safety on their own doesn't literally mean on their own; they are relying on tooling.

True Scotsman's "on your own" means working in assembly language, in which you have to carefully manage even just calling a function and returning from it: not leaving stray arguments on the stack, saving and restoring all callee-saved register that are used in the function and so on.

Someone who thinks that their job is not to have segfaults is pretty green, obviously.

blub3• 8 months ago

Sounds like a straw-man. I know developers who are good enough to achieve it on their own, but they use the tooling anyway, because one can’t write perfect code always: feature requests might be coming in too fast, team members have different skill levels, dev turnover happens, etc.

Furthermore, memory bugs still can be considered by teams as just another bug, so they might not get prioritised.

The only significant difference is that there’s lots of criminal energy targeting them, otherwise nobody would care much.

Ar-Curunir• 8 months ago

Hopefully, there are no memory safety skeptics, other than rhetorical strawmen.

There are plenty of such skeptics. It's why Google, Microsoft, etc all needed to publish things like "70% of our vulnerabilities are memory-safety linked".

Even today, the increasing popularity of Zig indicates that memory-safety is not taken as a baseline.

MeetingsBrowser• 8 months ago

Good point. There are even two posts about Zig on the front page along side this post.

pjmlp9• 8 months ago

Indeed Zig would be interesting 30 years ago, when Modula-2 and Object Pascal were all over the place, and writing full games in Assembly was still seen as pretty normal.

AlotOfReading6• 8 months ago

I wish memory safety skepticism was nothing more than a rhetorical strawman. It's not hard to find prominent people who think differently though. Take Herb Sutter for example, who argues that "memory safety" as defined in this article is an extreme goal and we should instead focus on a more achievable 95% safety instead to spend the remaining effort on other types of safety.

I can also point to more extreme skeptics like Dan O'dowd, who argue that memory safety is just about getting gud and you don't actually need language affordances.

Discussions about this topic would be a lot less heated if everyone was on the same page to start. They're not. It's taken advocates years of effort to get to the point where we can start talking about memory safety without immediate negative reactions and that process is still ongoing.

bmurphy1976• 8 months ago

I prefer to treat testing like insurance. You purchase enough insurance to get the coverage you need, and not a penny more. Anything beyond that could be invested better.

Same thing with tests, get the coverage you need to build the confidence in your codebase, but don't tie yourself in knots trying to get that last 10%. It's not worth it. Create some manual and integration tests and move one.

I feel like type safety, memory safety, thread safety, etc. are are all similar. Building a physics core to simulate the stability of your nuclear stockpile? The typing should be second to none. Building yet another CSV exporter? Who gives a damn.

Context is so damn important.

samdoesnothing3• 8 months ago

Take Herb Sutter for example, who argues that "memory safety" as defined in this article is an extreme goal and we should instead focus on a more achievable 95% safety instead to spend the remaining effort on other types of safety.

I don't really see how that's a) a scepticism of memory safety or b) how it's not seen as a reasonable position. Just because someone doesn't think X is the most important thing ever doesn't mean they are skeptical of it, but rather that the person holding the 100% viewpoint is probably the one with the extreme position.

kazinator6• 8 months ago

It's hard to imagine that if a memory problem were reported to Sutter about one of his own programs, that he would not prioritize fixing that, over most other work.

However, I imagine he would probably take into consideration the context. Who and what is the program for? And does the issue only reproduce if the program is misused? Does the program handle untrusted inputs? Or are there conceivable situations in which a user of the program could be duped by a bad actor into feeding the program a malicious input?

Imagine Sutter wrote a C compiler, and someone found a way to crash it. But the only way to reproduce that crash is via code that invokes undefined behavior. why would Herb prioritize fixing that over other work?

Suppose the user insists that he's running the compiler as a CGI script, allowing unauthenticated visitors to their site to compile programs, making it a security issue.

How should Herb reasonably reply to that?

edmccard• 8 months ago

Take Herb Sutter for example, who argues that "memory safety" as defined in this article is an extreme goal and we should instead focus on a more achievable 95% safety

I wonder how you figure out when your codebase has reached 95% safety? Or is it OK to stop looking for memory unsafety when you hit, say, 92% safe?

Measter3• 8 months ago

Take Herb Sutter for example, who argues that "memory safety" as defined in this article is an extreme goal and we should instead focus on a more achievable 95% safety instead to spend the remaining effort on other types of safety.

One thing I've noticed when people make these arguments is that they tend to ignore the fact that most (all?) of these other safeties they're talking about depend on being able to reason about the behaviour of the program. But when you violate memory safety a common outcome is undefined behaviour, which has unpredictable effects on program behaviour.

These other safeties have a hard dependency on memory safety. If you don't have memory safety, you cannot guarantee these other safeties because you can no longer reason about the behaviour of the program.

recursivecaveat• 8 months ago

I would not describe Herb as a memory safety skeptic. He's a skeptic of what is practically achievable w/r/t memory safety within the C++ language and community. All 100% memory safe evolutions of the language are guaranteed to break so much that they receive near zero adoption. In that context I think it makes sense to talk about what version of the language can we create to catch the most errors while actually getting people to use it.

vlovich12314• 8 months ago

I’m curious, what memory safe alternative is there for a C/C++ codebase that doesn’t give up performance?

Also for what it’s worth Rust ports tend to perform faster according to Russinovich. Part of that may be second system syndrome although the more likely explanation is that the default std library is just better optimized (eg hash tables in Rust are significantly better than unordered_map)

bluGill3• 8 months ago

Ada has been around for years. The approach to memory safety isn't as strong as Rust, but it is a lot strong than C or C++. C++ is also adding a lot of memory safety, it is a lot easier to bypass than it is in Rust (though I've seen Rust code where everything is marked unsafe), but you still get some memory safety if you try.

All benchmarks between Ada, C, C++, and Rust (and others) should come down to a wash. A skilled programmer can find a difference but it won't be significant. A skilled C++ programmer wouldn't be using unordered_map so it is unfair to point out you can use something bad.

themafia2• 8 months ago

Part of that may be second system syndrome

It may be that they've implemented it differently in a way that is more performant but has fewer features. A "rust port" is not automatically or apparently a 1:1 comparison.

kazinator6• 8 months ago

A lot of Rust versus C or C++ comparisons be like: "Yo, check this Rust rewrite of Foo, which runs 2.5 faster¹ than the C original²".

---

1. Using 8 cores.

2. Single-threaded

littlestymaar• 8 months ago

Rust skeptics are not memory safety skeptics

Definitely not all of them, yes.

Hopefully, there are no memory safety skeptics, other than rhetorical strawmen.

You'll find the reality disappointing then…

nightpool2• 8 months ago

There was an article about Zig on the front page just a few hours ago that attracted many "Why do I need memory safety?" comments. The fact that new languages like Zig aren't taking memory safety as a foundational design goal should be evidence enough that many people are still skeptical about its value

tptacek20• 8 months ago

Zig's approach to memory safety is an open question. I don't like it (obviously, a very subjective statement), but as more software is written in it, we'll get empirical data about whether Zig's bet pays off. It very well might.

antonvs• 8 months ago

Tell me more about memory safety

What is it you want to hear about memory safety? If you’re willing to accept the tradeoffs of an automatic garbage collector, memory safety has been a solved problem for decades, and there’s not a whole lot to tell you about it other than learning about widespread, mature technology.

But if you have some good reason to avoid that technology, then your options are far more limited, and there are good reasons that Rust dominates that conversation.

So the question stands - what is it you want to hear more about?

pjmlp9• 8 months ago

For example, everyone that is already more than happy using any form of automatic resource managed programming language.

Many have no use for borrow checker, and there is already enough choice with ML inspired type systems.

eptcyka2• 8 months ago

Rust certainly was not the first "systems programming" language that was memory safe, ADA was aiming for the same title and I think achieved it way before Rust.

Yoric6• 8 months ago

While Ada is a great and sadly underused language, if my memory serves, it's not out-of-the-box memory-safe by today's definitions. I seem to recall that it takes Spark to make it memory-safe.

themafia2• 8 months ago

by today's definitions.

What are todoay's definitions? If Ada simply had more thorough rules but introduced an "unsafe {}" construct, then what would the practical difference actually be? Compiler defaults?

RavSS• 8 months ago

SPARK is practically just a restricted version of Ada with a few added features for formal verification. You can write a program primarily in SPARK but disable said restrictions based on circumstance by setting the `SPARK_Mode` pragma/aspect to `off` on a package, procedure, function, etc. Mixing Ada and SPARK is trivial.

I guess it is similar to Rust code that uses `unsafe {}` as the other poster mentioned (maybe `unsafe fn` for a closer analogy). My knowledge of Ada/SPARK is much greater than what I know about Rust, so I might be guessing wrong.

pjmlp9• 8 months ago

SPARK is like Ada's version of Rust's clippy.

fulafel2• 8 months ago

Also Go (and arguably Java). Managed languages work and are regularly used for systems programming.

surajrmal3• 8 months ago

That depends on your definition of systems programming. Go and java are not fit for low level OS or embedded development. They are too memory hungry. A lot of software runs on hardware other than servers. iot, auto, tvs, phones, watches, etc all have much tighter requirements on acceptable software overhead from languages employed. Also, the more memory and CPU you use in systems layers, the less that is available for higher level layers, which are often written in higher level languages and desire the majority of the devices resources.

pjmlp9• 8 months ago

Neither was Ada, JOVIAL, ESPOL and NEWP rank among the very first ones, a decade before C.

Even PL/I had a higher security score given by the DoD, than C.

faustocarva• 8 months ago

a roughly 70 percent reduction in memory-safety vulnerabilities.

Couldn't find this in the reference text. Is it my interpretation? https://www.memorysafety.org/docs/memory-safety/#how-common-...

burakemir3• 8 months ago

This is a good article.

Small nit: As someone curious about a definition of memory safety, I had come across Michael Hicks' post. He does not use the list of errors as definition, and argues that such a definition is lacking rigor and he is right. He says;

Ideally, the fact that these errors are ruled out by memory safety is a consequence of its definition, rather than the substance of it. What is the idea that unifies these errors?

He then offers a technical definition (model) involving pointers that come with capability of accessing memory (as if carrying the bounds), which seems like one way to be precise about it.

I have come to the conclusion that language safety is about avoiding untrapped errors, also known as "undefined behavior". This is not at all new, it just seems to have been forgotten or was never widely known somehow. If interested, find the argument here https://burakemir.ch/post/memory-safety-the-missing-def/

tptacek20• 8 months ago

What's important is the context in which the term is used today: it's specifically about security and software vulnerabilities, not about a broader notion of correctness and program reliability. Attempts to push past that have the effect of declaring languages like Java and Python memory-unsafe, which is not a defensible claim.

burakemir3• 8 months ago

This is a false dichotomy. Language design choices are the causes of security and software vulnerabilites. It is possible to recognize the value of GC languages and have precise technical terminology at the same time. We can invent new words.

I believe everyone who cares about memory safety appreciates that certain bugs cannot occur in Java and go, and if the world calls that memory safe, that is ok.

There are hard, well-defined guarantees that a language and implementation must make, and a space of trade-offs. We need language and recognition for the ability to push the boundary of hard, well-defined guarantees further. That, too, is memory safety and it will be crucial for moving the needle beyond what can be achieved with C and C++.

No one has a problem with applications being ported from low-level to GC-ed languages, the challenge is the ones where this is not possible. We need to talk about memory safety in this specific context, and mitigations and hardening will not solve the entire problem, only pieces of it.

pizlonator3• 8 months ago

This article comes up with yet another definition of memory safety. Thankfully, it does not conflate thread safety with memory safety. But it does a thing that makes is both inaccurate (I think) and also not helpful for having a good discussion:

TFA hints at memory safety requiring static checking, in the sense that it's written in a way that would satisfy folks who think that way, by saying thingys like "never occur" and including null pointer safety.

Is it necessary for the checking to be static? No. I think reasonable folks would agree that Java is memory safe, yet it does so much dynamic checking (null and bounds). Even Rust does dynamic checking (for bounds).

But even setting that aside, I don't like how the way that the definition is written in TFA doesn't even make it unambiguous if the author thinks it should be static or dynamic, so it's hard to debate with what they're saying.

EDIT: The definition in TFA has another problem: it enumerates things that should not happen from a language standpoint, but I don't think that definition is adequate for avoiding weird execution. For example, it says nothing about bad casts, or misuses of esoteric language features (like misusing longjmp). We need a better definition of memory safety.

tptacek20• 8 months ago

I want to be there with you, but the definition this piece uses is, I think, objectively the correct one --- "memory safety", at least as used in things like "The Case For Memory Safe Roadmaps" government guidance, is simply the property of not admitting to memory corruption vulnerabilities.

I don't see where you're seeing the article drawing a line between static and dynamic defenses. The article opens by noticing Rust isn't the first memory safe language. It is by implication referring to things like Java, which have dynamic, runtime-based protections against memory corruption.

pizlonator3• 8 months ago

I want to be there with you, but the definition this piece uses is, I think, objectively the correct one --- "memory safety", at least as used in things like "The Case For Memory Safe Roadmaps" government guidance, is simply the property of not admitting to memory corruption vulnerabilities.

This piece does not define memory safety as "not admitting memory corruption vulnerabilities". If it was using that definition, then:

- You and I would be on the same page.

- I would have a different complaint, which is that now we have to define "memory corruption vulnerability". (Admittedly, that's maybe not too hard, but it does get a bit weird when you get into the details.)

The definition in TFA is quoted from Hicks, and it enumerates a set of things that should never happen. It's not defining memory safety the way you want.

bgwalter13• 8 months ago

TFA is too long, like all articles since the arrival of you know what. So the definitions are scattered. Here it claims:

Rust's big step function was to offer memory safety at compile time through the use of static analysis borrowed and grown out of prior efforts such as Cyclone, a research programming language formulated as a safe subset of C.

In other words, Rust has solved the halting problem since the static checking of array bounds is undecidable in the general case!

Jtsummers2• 8 months ago

In other words, Rust has solved the halting problem

No one is making that claim.

tialaramex5• 8 months ago

Nope. You don't need to "solve the halting problem" and I guess I'll explain why here.

Firstly lets attack the direct claim. The reason you'd reduce to the halting problem is via Rice's theorem. But, Rice only matters if we want to allow exactly all the programs with the desired semantics. In practice what you do is either allow some incorrect programs too (like C++ does, that's what IFNDR is about, now some programs have no defined behaviour at all, but oh well, at least they compiled) or you reject some correct programs too (as Rust does). Now what we're doing is merely difficult rather than provably impossible, and people do difficult things all the time.

This is an important choice (and indeed there's a third option but it's silly, you could do both, rejecting some correct programs while allowing some incorrect ones, the worst of both worlds) but in neither case do we need to solve an impossible problem.

Now, a brief aside on what Rust is actually doing here, because it'll be useful in a moment. Rust's compiler does not need to perform a static bounds check on array index, what Rust's compiler needs to statically check is only that somebody wrote the runtime check. This satisfies the requirement.

But now back to laughing at you. While in Rust it's common to have fallible bounds checks at runtime (only their presence being tested at compile time) in WUFFS it's common for all the checks to be at compile time and so to have your code rejected if the tools can't see why your indexing is always in bounds.

When WUFFS sees you've written arr[k] it considers this as a claim that you've proved 0 <= k < arr.len() if it can't see how you've proved that then your code is wrong, you get an error. The result is that you're going to write a bunch of math when you write software, but the good news is that instead of going unread because nobody reviewing the code bothered reading the maths the machine read your math and it runs a proof checker, so if you were wrong it won't compile.

Edited: Fix off-by-one error

lmm11• 8 months ago

In other words, Rust has solved the halting problem since the static checking of array bounds is undecidable in the general case!

Pfft, the simply typed lambda calculus solved the halting problem back in 1940.

creatonez3• 8 months ago

Are you responding to an AI hallucinated version of this article? It doesn't say what you're saying it does.

_zagj• 8 months ago

It seems obvious that with hardware-level memory safety on the way[1], just gradually modernizing existing C and C++ codebases to take advantage of safer constructs (like smart pointers or checked arithmetic) makes much more sense than rewriting everything in Rust. Even better, thanks to GCC, is that you don't need to sacrifice any portability to take advantage of even bleeding-edge features, due to its front-end/back-end separation and multitude of supported platform back-ends. Fish shell had to drop support for some platforms when it was rewritten in Rust[2].

[1] https://community.intel.com/t5/Blogs/Tech-Innovation/open-in...

[2] http://fishshell.com/blog/rustport/

dwattttt4• 8 months ago

It seems obvious that with hardware-level memory safety on the way[1], just gradually modernizing existing C and C++ codebases to take advantage of safer constructs (like smart pointers or checked arithmetic) makes much more sense than rewriting everything in Rust

I read this in the opposite way: if the hardware is going to be stricter about memory accesses being valid, that suggests that software is going to have to meet a higher standard in order to successfully run.

Imagine if you had to satisfy the Rust borrow checker, except you're still writing C and don't have additional tooling during compilation to show how a problem could trigger, you just have more crashes.

TinkersW2• 8 months ago

Ya ever heard of this thing called a debugger? They have this amazing ability to show you what the problem is right when it happens!

creatonez3• 8 months ago

Fish shell had to drop support for some platforms when it was rewritten in Rust

Weird misrepresentation of your source... they had to drop support for only the obscurest of platforms, and concluded "We don’t see a big problem here".

Rust has enormous platform support. See https://doc.rust-lang.org/nightly/rustc/platform-support.htm... for a list. It also has the backend/frontend separation you describe, because it is based on clang internals. There is also ongoing work to plug it into GCC, as well as Rust compilers that can output C code directly to target dead embedded platforms that only have a single proprietary C compiler.

vlovich12314• 8 months ago

Hardware level memory safety doesn’t solve bugs caused by the compiler seeing UB in your code and choosing to emit different code than you intended.

bgwalter13• 8 months ago

If the 5 eye agencies recommend memory safety, can we conclude that they already get all their information via "AI" data harvesting in Office 365 and similar? What will happen to Pegasus? Or do they have yet unknown backdoors in Rust?

adrianN3• 8 months ago

I believe they also recommend encryption but I wouldn’t conclude that encrypted data doesn’t make their job harder.

bgwalter13• 8 months ago

They do indeed recommend encryption, sometimes with deliberate backdoors: https://en.wikipedia.org/wiki/Dual_EC_DRBG

So viewing their recommendations with caution seems wise.

iambvk5• 8 months ago

What is the justification to call `Null pointer dereference` as a memory safety issue?

K0nserv2• 8 months ago

It's worse than a memory safety issue, it's undefined behaviour (at least in C, C++, and Rust)

tptacek20• 8 months ago

UB is in fact not worse than a memory safety issue, and the original question is a good one: NULL pointer dereferences are almost never exploitable, and preventing exploitation is the goal of "memory safety" as conceived of by this post and the articles it references.

iambvk5• 8 months ago

Doesn't null-pointer-dereference always crash the application?

Is it only an undefined-behavior because program-must-crash is not the explicitly required by these languages' specs?

igregoryca• 8 months ago

1) Null pointer derefs can sometimes lead to privilege escalation (look up "mapping the zero page", for instance). 2) As I understand it (could be off base), if you're already doing static checking for other memory bugs, eliminating null derefs comes "cheap". In other words, it follows pretty naturally from the systems that provide other memory safety guarantees (such as the famous "borrow checker" employed by Rust).

immibis2• 8 months ago

Both Linux and Windows forbid mapping the zero page.

matu3ba3• 8 months ago

1 The numbers on memory safety should nowadays separate between spatial ones (bounds-checked in most languages with sane flags) and temporal ones. Temporal ones will be lower than 70%.

2 The article does not mention (compilation) time costs of static checks and its influence on growing code bases, which is a more fundamental system trade-off on scalability and development velocity/efficiency.

Wrap unsafe code with safe interfaces

3 That sounds like an equivalent of using permission-based separation logic hopefully soon available for LLVM.

"Get good" is not a strategy

4 Being good is all about knowing exactly techniques, processes, and tools with exact trade-offs and applying them; so I would expect here teaching process knowledge about static and dynamic analysis strategies, tooling and tactics to eliminate bug classes. However, neither have we sane bug classes overviews nor can we generate sane probabilities/statistics of occurrence based on source code and available static and dynamic analysis even when ignoring functionality requirements. This reads somewhat like developers should "stay mediocre" and "trust the tools", even though "Get good and improve processes for groups" is probably the here intended strategy.

tptacek20• 8 months ago

What do you mean by "temporal ones will be lower than 70%"? Are you suggesting --- referring to the article's cite --- that subcomponent ports to Rust reduce spatial vulnerabilities more than temporal ones? If so, why do you believe that?

matu3ba3• 8 months ago

I would expect more of the opposite for languages offering easy to enable bound checks. Only observing the general trend for when bound checks are available (and used) would be helpful information. Temporal ones will remain tricky to debug until at least static + dynamic analysis via scheduling in kernel, hypervisor/simulation and/or run-time will become common-place. Probably even longer, because analysis is cumbersome for bigger programs without Seperation Logic (like Rust has).

TinkersW2• 8 months ago

I think memory safety is fine, but I plan to do it in C++ not Rust-- nothing in this article is remotely new either, just repeating the same tired stuff.

It seems pretty clear statistical hardware level memory safety is coming(Apple has it, Intel/AMD have a document saying they are planning to add it), the safety zealots can turn that on, or you can use FilC if you need absolute memory safety, but really C++ with various hardening features turned on is already fairly solid.

Also I think that memory safety is generally less important than thread safety(because memory safety is rather easy to achieve and detect violations), which almost all those languages recommended by this article blow chunks at. Rust could actual make a solid argument here, instead of wasting time yammering about memory safety.

vlovich12314• 8 months ago

Rust’s thread safety story is a subset of broader memory safety - it just guarantees that concurrent programs still are memory safe. This also happens to correspond to the most frequent sources of bugs in concurrent programs, but it’s not all there is to thread safety.

It’s talked about all the time but whenever people talk about memory safety, thread safety is implied. Statistical hardware memory safety is more a security feature. But knowing that your code is correct before you even try it is a huge productivity boost and valuable in and of itself for all sorts of reasons.

It’s weird the pushback from c++ people considering that Rust makes high performing code easier to achieve because of rules around aliasing and auto-optimizing struct layouts among other things. This is stuff c++ will never get.

mk89• 8 months ago

Some days ago I took again a look at Rust.

I don't like the syntax at all, and coming from a Scala background that should say a lot. I will never like it, unless they simplify it.

However, they implemented at compile time all the rules that someone wrote in the CPP guidelines about memory, or in dozens of books about how to write safe code.

Now you can say: so you see, if you are good at c++, you achieve the same as Rust.

True. But I don't buy it. I don't believe that even hardcore c++ developers never make a memory related mistake. I have been in the industry for a while and shit does happen, even to the best of us, unless you have "guardrails" around, and even then, so many things can go wrong...

So a few days ago I asked on HN why not to use hardened allocators, which would basically block entirely the possibility to deploy such mistakes, a bit like OpenBSD allocator.

It seems 1) people who develop low level stuff don't even need the heap, or use anyways a limited subset of things, 2) such allocators slow down the runtime significantly.

So what I hear is:

1) I know what I am doing, I don't need a compiler to tell me that.

2) I anyway need a subset of that, so ... who cares.

3) runtime tooling helps me.

Except for 2 (like writing something for Arduino or by using some very specific subsets of C/C++), everything else sounds pretty much hypocrite to me, and the proof is that even the top of the top of the engineers have to fix double free or things like that.

If C++ broke the ABI and decided tomorrow to adopt memory safety at compile time, you would see that most people would use it. However, this holy war against Rust "because" is really antithetical of our industry which should be driven by educated people that use the right tool for the right job. As I said, ok for very low level/subsets, but why would you start today a CLI tool in C/C++ (if not for some very specific reasons )?

For me this has more with fear of learning/doing something new. It makes no sense otherwise to reject a language that guarantees that a random developer missed the lifetime of that object etc... A language that is only improving, not dying anytime soon, with one of the fastest growing ecosystem, not "one person's weekend project" or things like that.

As I mentioned multiple times, I dislike particularly Rust syntax. I love the C syntax the most, although C++ has deviated from that significantly with templates etc. But if something is better suited, sorry, we need to use it. If the C/C++ committee are the slowest things on the planet, why should my company/software pay for that? Everyone said python would die after the backward incompatible 2->3 upgrade. Sure.

fainpul• 8 months ago

What if, instead of fighting the symptom of people writing faulty, exploitable software, by explaining to them that Rust (as a stand in) is good, we try to fix the cause?

Imagine if for every data breach, every ransomware attack, every intrusion which used privilege escalation etc. there would be an investigation if the company in question is at fault for using insecure software (i.e. written in unsafe languages and not properly vetted). And if the company is found guilty, it is punished accordingly, so that every company is motivated to prevent such cases.

Of course people can still write C / C++ programs as a hobby or publish their software with open source licenses. But the people or organizations using that software must make sure (within reason) that it is safe or they are held liable if it inflicts damage. It would automatically make software written in safe languages much more attractive to them, because safety is much easier to prove – no evangelist needed.

Memory Safety for Skeptics

Related Stories