2 ms·

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

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.
        Schroedingersat 4y ago
        Guarantee =/= capability. There are plenty of tools in the language and ecosystem for dealing with memory errors and reducing their frequency, but you're clearly not interested in a rational discussion.
  - Tozen 4y ago
    But isn't the position of a "Better C", already covered too, by languages such as D? And I mean literally too, with their "-betterC". There is arguably no place for Zig to go, along the "better C" route, that hasn't been covered by other languages. And languages like D and Object Pascal, are way up on the charts, so it will be a hard climb to reach them in popularity. Even the much older Nim language (which has been called a C alternative), still hasn't cracked the top 50, among language rankings. Debatably, a language's "claim to fame" (to escape niche status), can't just be about being a more complex C replacement. There has to be other things about it, that it can firmly stand on, for greater mass appeal.
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/

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.
      - Schroedingersat 4y ago
        Guarantee =/= capability. There are plenty of tools in the language and ecosystem for dealing with memory errors and reducing their frequency, but you're clearly not interested in a rational discussion.
- Tozen 4y ago
  But isn't the position of a "Better C", already covered too, by languages such as D? And I mean literally too, with their "-betterC". There is arguably no place for Zig to go, along the "better C" route, that hasn't been covered by other languages. And languages like D and Object Pascal, are way up on the charts, so it will be a hard climb to reach them in popularity. Even the much older Nim language (which has been called a C alternative), still hasn't cracked the top 50, among language rankings. Debatably, a language's "claim to fame" (to escape niche status), can't just be about being a more complex C replacement. There has to be other things about it, that it can firmly stand on, for greater mass appeal.

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/