Hacker News Reader

Comment by mgaunard | Hacker News Reader

Memory-safe languages are IMHO a distraction from making people write bug-free code.

There are much more important bugs than memory safety bugs, including all sorts of performance bugs.

We need to address the whole spectrum instead of compromising all areas in order to tackle niche bugs that only matter in security-critical contexts.

View on HN

This isn't true in practice.

When you don't have to worry about memory safety, your brain is freed up to worry about other kinds of bugs.

The other bit of good news is that the sorts of things Rust does to have memory safety also enable the systematic elimination of many other kinds of bugs. For example, iterator invalidation.

For example, the easiest way to make programs avoid use-after-free errors is to never free things.

Would you rather get a program that constantly use all of your RAM until you restart it, or one that consistently uses very little, but someone crashes in edge cases?

I'd rather use a program that uses as little memory as possible and that also never crashes. With Rust you can just have both.

That's not really what happens. Most Rust code actually does whatever is easiest to get the borrow checker to stop complaining, including extending lifetime beyond the scope that is necessary, and putting reference counting everywhere.

I'm not one to boast, but at least my Rust code doesn't do that much. Feel free to have a look, basically all the professional Rust code I've ever written is free software.

Rust is a lot better than GC languages at memory usage, and (because borrowing is actually safe) a bit better than C++.

Sure, if you never use unsafe, or anything that uses unsafe, transitively.

Memory unsafety is a property of von Neumann architectures, and explicit unsafe limits the scope of damage significantly.

I have made major contributions to several Rust projects that have collectively saved organizations over $100MM in production, if not more. I worry about lots of things, but crashes just aren't one of them.

Good luck not releasing stack frames.

Talked like somebody that doesn't understand the stack at all.

On Linux, the stack grows automatically and never shrinks.

Sure, the stack as storage never shrinks, but it's constantly reused for different kinds of objects. Having said that dynamic memory is also rarely given back to the OS, and you are lucky to get a segfault from a use-after-free there too. This is not the problem.

The problem is accessing objects that are outside of their lifetime, not storage. The objects are gone, even if the storage might still be there.

That's not as big of a problem as using more resources than you need.

Use-after-return is a subset of use-after-free bugs. Allocate a temporary on the stack, pass it by reference to somewhere that outlives that function, and then watch your program explode. No dynamic memory allocation at all.

Escape analysis can easily determine if a temporary/local value that would by default be allocated on the stack outlives the function in which it was declared, and in that case can move the allocation to the heap instead.

Sort of. If your approach is "never free things" then you probably want to know pretty clearly what allocations will produce leaks and a sound escape analysis is going to definitely report some allocations that are unexpected.

But this isn't the hard part.

Since you need to edit your compile to modify allocations, this needs to be a global analysis. If you've got a function that takes a parameter by reference and returns it by reference, you need to adjust the allocations at the call site to be on the heap if the return value outlives the allocation. But... now you've broken separate compilation and need this to run as a global pass with lto. And enjoy all of your false positives caused by sound call graph analysis in a world where you've got virtual and indirect function calls. And what about a local that is stored by reference as a field of an object and then that object is passed by reference to a function? Now you need an object-sensitive pointer analysis. During your compile.

And then there are all of the ordinary problems with C++ that make sound static analysis nightmarish. One of these things havocs and blows everything up to Top and you are quickly yelling at your compiler.

I dunno, Go does it pretty effectively, are they cheating or something?

It’s not true that memory safety bugs only matter in security-critical contexts. If a program segfaults, it’s going to make the user unhappy regardless of security implications.

And don't forget that a segfault is the lucky case in matters of memory safety bugs. I've worked on many memory safety bugs that manifested themselves by silently corrupting data.

What kind of niche bugs are you speaking of?

For what it's worth, Rust (and other languages of ML heritage) are really good at getting rid of huge categories of bugs, not just memory. Not all bugs, of course.

The problem with memory safety bugs is that the capacity for unwanted behavior is much higher. This is why they are useful as security vulnerabilities when crafting exploits. They can turn your program into an unbounded one that can compute anything. It also means "uh, we just stored garbage data where there should be a key and now the entire encrypted blob is irrecoverable."

> all sorts of performance bugs

A lot of code is written in safe, slow languages that could be written in a safe, fast language.

Making all vector accesses bounds-checked, as all memory-safe languages do, is a recipe for slow code.

You can try turning on hardened libc++ and see what performance hit you get. It isn't really too bad. And a considerable portion of that is waste caused by other design choices in C++ making it difficult for the compiler to remove redundant bounds checks.

The term "Memory safety" also heavily undersells what it actually implies in Rust.

Memory safety bugs are second only to segfaults in terms of importance.

In terms of the actual bugs encountered when developing modern C++ applications, logic bugs vastly outnumber segfaults and memory safety bugs, which are quite rare when you're writing business logic.

I fully agree. Memory safety issues are a small minority of C++ issues. Memory safety issues when you get them are very difficult to track down, and often have much broader/worse effects.

With an MMU, segfaults cause pretty abrupt and obvious failures for straying outside the heap or stack. Violating memory safety may cause subtle and unpredictable errors even in correct functions, which is a lot more dangerous.

No argument there!

Segfaults are a result of violating memory safety. They are the BEST case since you can actually detect the program yolo'd

Far worse is your program starts corrupting your data and suddenly you are executing a routine you had no intention of ever executing

Not really. Not all memory safety violations result in segfaults, and not all segfaults are the result of memory safety violations.

Which segfaults are NOT the result of memory safety violations?

Uh, most? Memory safety is about data races and concurrent access violations. De-referencing a nil pointer isn't a memory safety violation, for example. But I guess if you re-define memory safety to mean anything that can produce a segfault then sure.

Reply on news.ycombinator.com