7 ms·

> In practice, it's not an issue, and unlike with rust I have a very clear idea of when and where memory is being freed and allocated. I'm very skeptical that

> In practice, it's not an issue, and unlike with rust I have a very clear idea of when and where memory is being freed and allocated. I'm very skeptical that the lack of memory safety is not going to be an issue "in practice". That's what every C++ developer thinks too until they write code people actually try to attack. One of the very nice things about memory safety is that it frees the programmer from having to think about when memory is freed most of the time. The compiler or runtime system will take care of that. Most of the time, manual frees are just noise--this observation is the entire reason behind destructors.

LAC-Tech 4y ago
Learn Zig and get back to me. It's nothing at all like managing memory in C++, not even close.
- pcwalton 4y ago
  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.
  - 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
dagmx 4y ago
I’ve met a lot of seasoned C++ developers who tell me the memory safety won’t be an issue in practice. Hell, I’m sure I’ve said it before too. I’ve yet to meet one who actually didn’t end up with some safety issue in their code. Not all of their code mind you, but even a couple times can be significant. Like you, I like memory safe languages because they let me think about my problem and trust the tooling to catch entire classes of mistakes for me
- zackees 4y ago
- dataflow 4y ago
  > I’ve met a lot of seasoned C++ developers who tell me the memory safety won’t be an issue in practice. Hell, I’m sure I’ve said it before too. The claim I've heard (and I think also made) is a bit different from that. It's more like: "dealing with memory corruption issues isn't a significant portion of the debugging effort in [idiomatic] C++ code". i.e. the claim is not that you somehow won't run into them; rather, the claim is that they form a small fraction of the actual bugs you run into (either count-wise or time-wise), if you're writing C++ "properly". (If I had to make up a number, I'd say < 5%.) This obviously isn't to say memory safety isn't an issue, or that security is a negligible property. Rather, it's to point out that most issues are of a different kind, and if you think that memory safety will decrease your workload significantly, that's unlikely to be the case if you're writing C++ with the correct idioms. I think this response is usually in response to claims about how (say) a language like Rust results in N times faster development than C++. If that's truly the case, it's unlikely to be due to memory safety per se, but due to other factors.
  - verdagon 4y ago
    To add to that, there are some applications for which memory unsafety just doesn't cause that much harm. I worked on a very large C++ codebase that compiled to webassembly, which runs sandboxed in people's browsers. It only talked to one (trusted) server. Like any project, we had plenty of logic bugs every release. They would often result in odd artifacts on the screen and sometimes a crash. Only 5% of our bugs were related to memory unsafety, and they also resulted in odd artifacts on the screen and sometimes a crash. In other words, memory unsafety wasn't much of a concern in practice. It was as bad as any logic bug. This was the main reason we stuck with C++, rather than spend SWE-years migrating to a more memory-safe language. (I know this is ironic coming from me, who designs a memory-safe language full-time!)
ghoward 4y ago
Not GP. > I'm very skeptical that the lack of memory safety is not going to be an issue "in practice". For what it's worth, I agree with you. And I'm a C programmer that managed to put out a non-trivial piece of C code ([1]) that has had no memory safety issues triggered in the wild after 1.0 (which was released on 26 Oct 2018, so almost 4 years, yay!) that I know of. The truth is that I am not able to write such code; I just fuzz the ever-living daylights out of my code with lots of asserts to test all of the assumptions that my code makes, including preconditions, postconditions, everything. I also use static analysis, -Weverything on Clang (without -Wpadded; that's a stupid warning), and a massive test suite with near 100% coverage. In my new projects, I'm even using fuzzing to generate almost all of my test cases so that my path coverage is as good as possible. That's a lot of work, and it's not fun. But what would make it even more effective would be to effectively automatically add asserts for me to test the assumption that an index is in range whenever it is used! And that's why memory-safe languages are the only way to go: not only do they save people from bad code, they help programmers turn bad code into good code with the tools at their disposal. I think the Zig people know this, which is why they have ReleaseSafe for testing and for those cases where you have to be sure. But I also don't see them test their code enough for me to trust that it's not needed. And I doubt that Zig users test their code enough for it too. All of this is to say, I completely agree with you despite (so far!) being the exception to the rule you articulated, and I dread the day when my reign of "being the exception" comes to an end. I really want to stay being the exception. [1]: https://git.yzena.com/gavin/bc https://git.yzena.com/gavin/bc
- pjmlp 4y ago
  Congratulations for being part of the minority that cares, On my experience, only small teams with top devs do happen to care for doing the security work you describe, as tends to be proven by surveys regarding the use of unit testing or static analysis tooling, https://www.jetbrains.com/lp/devecosystem-2021/c/ https://www.jetbrains.com/lp/devecosystem-2021/c/ https://www.jetbrains.com/lp/devecosystem-2021/cpp/ https://www.jetbrains.com/lp/devecosystem-2021/cpp/ So yeah, pity that memory-safe languages have to fight back to regain what was already possible before UNIX took over the computing world and brought C for the ride. This is why I would like that Zig could offer more than Modula-2 already did in 1978, in regards to memory corruption.

LAC-Tech 4y ago

Learn Zig and get back to me. It's nothing at all like managing memory in C++, not even close.

pcwalton 4y ago
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.
- 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

dagmx 4y ago

I’ve met a lot of seasoned C++ developers who tell me the memory safety won’t be an issue in practice. Hell, I’m sure I’ve said it before too. I’ve yet to meet one who actually didn’t end up with some safety issue in their code. Not all of their code mind you, but even a couple times can be significant. Like you, I like memory safe languages because they let me think about my problem and trust the tooling to catch entire classes of mistakes for me

zackees 4y ago
dataflow 4y ago
> I’ve met a lot of seasoned C++ developers who tell me the memory safety won’t be an issue in practice. Hell, I’m sure I’ve said it before too. The claim I've heard (and I think also made) is a bit different from that. It's more like: "dealing with memory corruption issues isn't a significant portion of the debugging effort in [idiomatic] C++ code". i.e. the claim is not that you somehow won't run into them; rather, the claim is that they form a small fraction of the actual bugs you run into (either count-wise or time-wise), if you're writing C++ "properly". (If I had to make up a number, I'd say < 5%.) This obviously isn't to say memory safety isn't an issue, or that security is a negligible property. Rather, it's to point out that most issues are of a different kind, and if you think that memory safety will decrease your workload significantly, that's unlikely to be the case if you're writing C++ with the correct idioms. I think this response is usually in response to claims about how (say) a language like Rust results in N times faster development than C++. If that's truly the case, it's unlikely to be due to memory safety per se, but due to other factors.
- verdagon 4y ago
  To add to that, there are some applications for which memory unsafety just doesn't cause that much harm. I worked on a very large C++ codebase that compiled to webassembly, which runs sandboxed in people's browsers. It only talked to one (trusted) server. Like any project, we had plenty of logic bugs every release. They would often result in odd artifacts on the screen and sometimes a crash. Only 5% of our bugs were related to memory unsafety, and they also resulted in odd artifacts on the screen and sometimes a crash. In other words, memory unsafety wasn't much of a concern in practice. It was as bad as any logic bug. This was the main reason we stuck with C++, rather than spend SWE-years migrating to a more memory-safe language. (I know this is ironic coming from me, who designs a memory-safe language full-time!)

ghoward 4y ago

Not GP. > I'm very skeptical that the lack of memory safety is not going to be an issue "in practice". For what it's worth, I agree with you. And I'm a C programmer that managed to put out a non-trivial piece of C code ([1]) that has had no memory safety issues triggered in the wild after 1.0 (which was released on 26 Oct 2018, so almost 4 years, yay!) that I know of. The truth is that I am not able to write such code; I just fuzz the ever-living daylights out of my code with lots of asserts to test all of the assumptions that my code makes, including preconditions, postconditions, everything. I also use static analysis, -Weverything on Clang (without -Wpadded; that's a stupid warning), and a massive test suite with near 100% coverage. In my new projects, I'm even using fuzzing to generate almost all of my test cases so that my path coverage is as good as possible. That's a lot of work, and it's not fun. But what would make it even more effective would be to effectively automatically add asserts for me to test the assumption that an index is in range whenever it is used! And that's why memory-safe languages are the only way to go: not only do they save people from bad code, they help programmers turn bad code into good code with the tools at their disposal. I think the Zig people know this, which is why they have ReleaseSafe for testing and for those cases where you have to be sure. But I also don't see them test their code enough for me to trust that it's not needed. And I doubt that Zig users test their code enough for it too. All of this is to say, I completely agree with you despite (so far!) being the exception to the rule you articulated, and I dread the day when my reign of "being the exception" comes to an end. I really want to stay being the exception. [1]: https://git.yzena.com/gavin/bc https://git.yzena.com/gavin/bc

pjmlp 4y ago
Congratulations for being part of the minority that cares, On my experience, only small teams with top devs do happen to care for doing the security work you describe, as tends to be proven by surveys regarding the use of unit testing or static analysis tooling, https://www.jetbrains.com/lp/devecosystem-2021/c/ https://www.jetbrains.com/lp/devecosystem-2021/c/ https://www.jetbrains.com/lp/devecosystem-2021/cpp/ https://www.jetbrains.com/lp/devecosystem-2021/cpp/ So yeah, pity that memory-safe languages have to fight back to regain what was already possible before UNIX took over the computing world and brought C for the ride. This is why I would like that Zig could offer more than Modula-2 already did in 1978, in regards to memory corruption.