4 ms·

We've had close to 50 years to answer the question "is memory safety necessary to write secure code under normal industry development practices"? During this ti

We've had close to 50 years to answer the question "is memory safety necessary to write secure code under normal industry development practices"? During this time dozens of languages have come and gone, and the evidence still overwhelmingly points to "yes". It's going to take a lot to make a convincing argument otherwise, especially since Zig doesn't really do much different from C here, semantically speaking.

LAC-Tech 4y ago
I've explained how Zig memory management is different. You've chosen to ignore that and just compare it C and C++. I've suggested you learn Zig. You've ignored that too, and just zeroed in on the fact it's "manual". Here's a car analogy - old manual vehicles had unsynchronised transmissions where the clutch had to be depressed twice per gear change. Newer manual vehicles use steering wheel mounted paddle shifters and the clutch only needs to be depressed when stopping or starting. You're trying to push your weird semi-automatic transmission - that a lot of people find unusable as a daily driver - by ranting about how awful double clutching is.
- pcwalton 4y ago
  Car analogies aren't a substitute for actually writing widely-attacked software. There are systematic reasons why I'm skeptical Zig's approach will lead to better results than what we see in modern C++. The worst memory safety issues from a security point of view tend to be use-after-free caused by complex, untested code patterns, where one programmer wrote, or implied, "free", without realizing that somewhere else in the millions-of-lines codebase some other part of the code, written by someone else, still had a reference to the object. Unit tests don't catch these problems because they're caused by strange patterns that the programmer didn't anticipate. That is the kind of vulnerability that is difficult to solve without either a compiler or a runtime system (GC) to help you, and I see nothing in Zig that solves it. You can, and people do, make raw pointers to other objects in Zig.
  - anonymoushn 4y ago
    In support of the parent who already knows all this: you don't even need to take raw pointers to have these problems! You'll usually get a slice from your allocator. Keeping any copy of that or any slice into that (e.g. a string in a struct obtained by deserializing a json document into a short-lived slab of memory) will get you use-after-frees too.
  - Schroedingersat 4y ago
    Zig is not trying to be a better C++, so I don't see how complaining that it isn't a better C++ is relevant. It's not trying to be for large, widely attacked projects. It's for things where the complexity overhead (whether resources or mental overhead) of Rust is too much, so you'd have to use C. It's not meant to make memory errors impossible, it's meant to make them much easier to avoid or find and remove than it is in C. Noone is suggesting anyone make a web browser in Zig, but it's likely useful for drivers or similar where you'd otherwise be using a lot of unsafe code, so rust's guarantees are at best a partial help, and at worst a false sense of security.
    - pjmlp 4y ago
      They could have used Object Pascal or Modula-2, and would get the same memory safety guarantees that Zig offers.
      - Schroedingersat 4y ago
        And it makes no pretense otherwise. Why bring this up?
        pjmlp 4y ago
        One would thought a C replacement in 2022 would have better hindsight regarding memory safety than what was already possible in 1978, which was actually even available in JOVIAL (1958), or ESPOL/NEWP (1961), among many other possible examples.
- nemothekid 4y ago
  I don't think pcwalton is a stranger to Zig; I'd be surprised if he hasn't played with it yet. Regardless my experience with Zig, is, as far as memory management was concerned, it was less powerful than C++. A UAF is still trivial in the language (the stdlib makes exploiting one pretty difficult); and the lack of smart pointers still seemed like a strange decision in our multi-threaded, multi-core world. This makes something like the use of sanitizers required for large projects in Zig; It's a race against time until your project gets big enough that someone mistakenly frees something that gets used 200 lines later.
  - throwaway17_17 4y ago
    Slightly off topic, but I would prefer to never see smart pointers in Zig. Smart pointers are an inefficient and semantically-unenforceable ‘solution’ for the wrong problem. Smart pointers are supposed to be a way to handle references to mutable data in concurrent/multi-threaded/distributed computation, however I don’t think they form a satisfactory basis to solve the problem they think they solve. Now, I’m not a fan of Rust’s approach in general or it’s approach to this problem, but at least it is a semantically motivated solution. If a Zig user wants to restrict usage of pointers in certain ways let them make their own data structures, but unless Zig is willing to alter its semantics including a ‘standard’ smart pointer is putting icing on a cardboard box. /edited to fix a typo/
thehaxerdude 4y ago
Rust is a terribly complex language, there are people at FAANG companies threatening to fork the language when attempts to simplify it are proposed. The amount of half-baked features present in the language are footguns in their own right. I love Rust, but I think Zig solves 70% of the memory safety problem at the benefit of a much simpler language.
- pcwalton 4y ago
  > Rust is a terribly complex language, there are people at FAANG companies threatening to fork the language when attempts to simplify it are proposed. Ironically, the person I think you're referring to is actually me, and that's a strong mischaracterization of what happened. Nobody was ever "threatening to fork the language". Besides, that's irrelevant to this discussion, because none of the complexity of Rust compromises memory safety. > I love Rust, but I think Zig solves 70% of the memory safety problem at the benefit of a much simpler language. I don't believe the 70% number without evidence. Again, the problem that we really need to solve is complex UAF caused by unexpected interactions between components of large software systems, and I see nothing in Zig to solve that.
- kaba0 4y ago
  The problem is that solving 70% of memory safety is arguably the same as solving 0% of it.
  - flohofwoe 4y ago
    So basically, using Rust is also entirely pointless as soon as it needs to call into non-Rust code (like operating system shared libraries)? ;) On a more serious note: IME most memory corruption issues in C and C++ are 'side effects' of the sloppiness of those languages (like not catching overflow, missing range checks, problems arising from implicit type conversions, sometimes just not compiling with warnings enabled, etc...). Zig enforces much more correctness (to a point where it is sometimes annoying to a C coder, but one quickly gets used to it), and it even does this when building C/C++ code (just by using much more 'picky' default compilation options than C/C++ compilers).
- 4y ago

LAC-Tech 4y ago

I've explained how Zig memory management is different. You've chosen to ignore that and just compare it C and C++. I've suggested you learn Zig. You've ignored that too, and just zeroed in on the fact it's "manual". Here's a car analogy - old manual vehicles had unsynchronised transmissions where the clutch had to be depressed twice per gear change. Newer manual vehicles use steering wheel mounted paddle shifters and the clutch only needs to be depressed when stopping or starting. You're trying to push your weird semi-automatic transmission - that a lot of people find unusable as a daily driver - by ranting about how awful double clutching is.

pcwalton 4y ago
Car analogies aren't a substitute for actually writing widely-attacked software. There are systematic reasons why I'm skeptical Zig's approach will lead to better results than what we see in modern C++. The worst memory safety issues from a security point of view tend to be use-after-free caused by complex, untested code patterns, where one programmer wrote, or implied, "free", without realizing that somewhere else in the millions-of-lines codebase some other part of the code, written by someone else, still had a reference to the object. Unit tests don't catch these problems because they're caused by strange patterns that the programmer didn't anticipate. That is the kind of vulnerability that is difficult to solve without either a compiler or a runtime system (GC) to help you, and I see nothing in Zig that solves it. You can, and people do, make raw pointers to other objects in Zig.
- anonymoushn 4y ago
  In support of the parent who already knows all this: you don't even need to take raw pointers to have these problems! You'll usually get a slice from your allocator. Keeping any copy of that or any slice into that (e.g. a string in a struct obtained by deserializing a json document into a short-lived slab of memory) will get you use-after-frees too.
- Schroedingersat 4y ago
  Zig is not trying to be a better C++, so I don't see how complaining that it isn't a better C++ is relevant. It's not trying to be for large, widely attacked projects. It's for things where the complexity overhead (whether resources or mental overhead) of Rust is too much, so you'd have to use C. It's not meant to make memory errors impossible, it's meant to make them much easier to avoid or find and remove than it is in C. Noone is suggesting anyone make a web browser in Zig, but it's likely useful for drivers or similar where you'd otherwise be using a lot of unsafe code, so rust's guarantees are at best a partial help, and at worst a false sense of security.
  - pjmlp 4y ago
    They could have used Object Pascal or Modula-2, and would get the same memory safety guarantees that Zig offers.
    - Schroedingersat 4y ago
      And it makes no pretense otherwise. Why bring this up?
      - pjmlp 4y ago
        One would thought a C replacement in 2022 would have better hindsight regarding memory safety than what was already possible in 1978, which was actually even available in JOVIAL (1958), or ESPOL/NEWP (1961), among many other possible examples.
nemothekid 4y ago
I don't think pcwalton is a stranger to Zig; I'd be surprised if he hasn't played with it yet. Regardless my experience with Zig, is, as far as memory management was concerned, it was less powerful than C++. A UAF is still trivial in the language (the stdlib makes exploiting one pretty difficult); and the lack of smart pointers still seemed like a strange decision in our multi-threaded, multi-core world. This makes something like the use of sanitizers required for large projects in Zig; It's a race against time until your project gets big enough that someone mistakenly frees something that gets used 200 lines later.
- throwaway17_17 4y ago
  Slightly off topic, but I would prefer to never see smart pointers in Zig. Smart pointers are an inefficient and semantically-unenforceable ‘solution’ for the wrong problem. Smart pointers are supposed to be a way to handle references to mutable data in concurrent/multi-threaded/distributed computation, however I don’t think they form a satisfactory basis to solve the problem they think they solve. Now, I’m not a fan of Rust’s approach in general or it’s approach to this problem, but at least it is a semantically motivated solution. If a Zig user wants to restrict usage of pointers in certain ways let them make their own data structures, but unless Zig is willing to alter its semantics including a ‘standard’ smart pointer is putting icing on a cardboard box. /edited to fix a typo/

thehaxerdude 4y ago

Rust is a terribly complex language, there are people at FAANG companies threatening to fork the language when attempts to simplify it are proposed. The amount of half-baked features present in the language are footguns in their own right. I love Rust, but I think Zig solves 70% of the memory safety problem at the benefit of a much simpler language.

pcwalton 4y ago
> Rust is a terribly complex language, there are people at FAANG companies threatening to fork the language when attempts to simplify it are proposed. Ironically, the person I think you're referring to is actually me, and that's a strong mischaracterization of what happened. Nobody was ever "threatening to fork the language". Besides, that's irrelevant to this discussion, because none of the complexity of Rust compromises memory safety. > I love Rust, but I think Zig solves 70% of the memory safety problem at the benefit of a much simpler language. I don't believe the 70% number without evidence. Again, the problem that we really need to solve is complex UAF caused by unexpected interactions between components of large software systems, and I see nothing in Zig to solve that.
kaba0 4y ago
The problem is that solving 70% of memory safety is arguably the same as solving 0% of it.
- flohofwoe 4y ago
  So basically, using Rust is also entirely pointless as soon as it needs to call into non-Rust code (like operating system shared libraries)? ;) On a more serious note: IME most memory corruption issues in C and C++ are 'side effects' of the sloppiness of those languages (like not catching overflow, missing range checks, problems arising from implicit type conversions, sometimes just not compiling with warnings enabled, etc...). Zig enforces much more correctness (to a point where it is sometimes annoying to a C coder, but one quickly gets used to it), and it even does this when building C/C++ code (just by using much more 'picky' default compilation options than C/C++ compilers).
4y ago