6 ms·

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

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.

School-Cotton 2y ago
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.
- Yoric 2y ago
  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.
kiitos 2y ago
Memory safety bugs are second only to segfaults in terms of importance.
- logicchains 2y ago
  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.
  - bluGill 2y ago
    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.
- erik_seaberg 2y ago
  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.
  - kiitos 2y ago
    No argument there!
- vitiral 2y ago
  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
  - kiitos 2y ago
    Not really. Not all memory safety violations result in segfaults, and not all segfaults are the result of memory safety violations.
    - vitiral 2y ago
      Which segfaults are NOT the result of memory safety violations?
      - kiitos 2y ago
        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.
Yoric 2y ago
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.
sunshowers 2y ago
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.
- mgaunard 2y ago
  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?
  - sunshowers 2y ago
    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.
    - mgaunard 2y ago
      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.
      - sunshowers 2y ago
        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++.
    - kiitos 2y ago
      Sure, if you never use unsafe, or anything that uses unsafe, transitively.
panstromek 2y ago
The term "Memory safety" also heavily undersells what it actually implies in Rust.
djur 2y ago
> all sorts of performance bugs A lot of code is written in safe, slow languages that could be written in a safe, fast language.
- mgaunard 2y ago
  Making all vector accesses bounds-checked, as all memory-safe languages do, is a recipe for slow code.
  - UncleMeat 2y ago
    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.
UncleMeat 2y ago
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."

School-Cotton 2y ago

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.

Yoric 2y ago
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.

kiitos 2y ago

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

logicchains 2y ago
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.
- bluGill 2y ago
  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.
erik_seaberg 2y ago
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.
- kiitos 2y ago
  No argument there!
vitiral 2y ago
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
- kiitos 2y ago
  Not really. Not all memory safety violations result in segfaults, and not all segfaults are the result of memory safety violations.
  - vitiral 2y ago
    Which segfaults are NOT the result of memory safety violations?
    - kiitos 2y ago
      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.

Yoric 2y ago

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.

sunshowers 2y ago

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.

mgaunard 2y ago
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?
- sunshowers 2y ago
  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.
  - mgaunard 2y ago
    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.
    - sunshowers 2y ago
      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++.
  - kiitos 2y ago
    Sure, if you never use unsafe, or anything that uses unsafe, transitively.

panstromek 2y ago

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

djur 2y ago

> all sorts of performance bugs A lot of code is written in safe, slow languages that could be written in a safe, fast language.

mgaunard 2y ago
Making all vector accesses bounds-checked, as all memory-safe languages do, is a recipe for slow code.
- UncleMeat 2y ago
  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.

UncleMeat 2y ago

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