4 ms·

> We do have the requisite data to answer whether preventing use-after-free is better than not preventing it. I expect Zig will prevent use-after-free. It will

by pron 7y ago

> We do have the requisite data to answer whether preventing use-after-free is better than not preventing it. I expect Zig will prevent use-after-free. It will be sound for safe code and unsound for unsafe code (by turning this on only in debug mode for testing). > but it's impossible to argue that not trying to prevent UAF is somehow safer. First, see above. Second, it is not only possible but even reasonable to argue that not trying to completely eliminate a certain error is very much safer. The reason is that soundness has a non-trivial cost which can very often be traded for an unsound reduction in a larger class of bugs. As an example, instead of soundly eliminating bugs of kind A, reducing bugs of kinds A, B and C -- for a similar cost -- may well be safer. There has been little evidence to settle whether sound elimination of bugs results in more correctness than unsound reduction of bugs or vice-versa, and it's a subject of debate in software correctness research.

pcwalton 7y ago
It's not interesting to talk about a system that might or might not exist in the future. (There is a word for that—"vaporware".) The point is that Zig doesn't even try to prevent UAF now, so you can't say that it's safer than languages that do prevent the problem. > As an example, instead of soundly eliminating bugs of kind A, reducing bugs of kinds A, B and C -- for a similar cost -- may well be safer. Hasn't this essentially been what C++ has been trying for memory safety for decades, without success? The C++ approach has been "smart pointers are good enough, and they prevent several other problems too", and the experience of web browsers (among others) has pretty much definitively shown: no, they really aren't. For memory safety, I would not bet on this approach.
- pron 7y ago
  > The point is that Zig doesn't even try to prevent UAF now I wouldn't say Zig exists at all right now, but just as it strives to one day be production-ready, it strives to prevent use-after-free. Safety is a stated goal for the language. > Hasn't this essentially been what C++ has been trying for memory safety for decades, without success? No. I'm talking about a mechanism that can detect various errors at runtime, and is turned on or off for various pieces of code and/or for all code at various stages of development. Rust, BTW, doesn't entirely guarantee memory-safety, either, when any unproven unsafe code is used, and even when it isn't (e.g., have you proven LLVM's correctness?). We always make some compromises on soundness; the question is where the sweet-spots are. Software correctness is one area where there are no easy answers and very few obvious ones.
  - pcwalton 7y ago
    > No. I'm talking about a mechanism that can detect various errors at runtime, and is turned on or off for various pieces of code and/or for all code at various stages of development What you are describing exists: ASan. We have a pretty good answer to the question "is ASan sufficient to prevent memory safety problems in practice": "no, not really". > Rust, BTW, doesn't entirely guarantee memory-safety, either, when any unproven unsafe code is used, and even when it isn't (e.g., have you proven LLVM's correctness?). We always make some compromises on soundness; the question is where the sweet-spots are. Empirically, Rust's approach has resulted in far fewer memory safety problems than previous approaches like smart pointers and ASan, with only garbage collectors (and restrictive languages with no allocation at all) having similar success in practice. Notice that the working approaches have something important in common: a strong system that, given certain assumptions, guarantees the lack of memory safety problems. Even though those assumptions are never quite satisfied in practice, empirically having those theoretical guarantees seems important. It separates systems that drastically reduce safety problems, such as Rust and GC languages, from those that do so less well, such as ASan and smart pointers. This is why I'm so skeptical of just piling on more mitigations: they're helpful, but we've been piling on mitigations for decades and UAF (for instance) is still a big a problem as ever.
    - pron 7y ago
      > We have a pretty good answer to the question "is ASan sufficient to prevent memory safety problems in practice" That is not the question we're interested in answering, and elimination of all memory errors is no one's ultimate goal, certainly not at any cost. By definition, unsound techniques will let some errors through. The question is which approach leads to an overall safer program for a given effort, and soundness (of properties of interest) always comes at a cost. (also, Zig catches various overflow errors better than ASan) > Empirically, Rust's approach has resulted in far fewer memory safety problems than previous approaches like smart pointers I don't doubt that, and if minimization of memory errors was programmers' primary concern (even in the scope of program correctness or even just security), there would be little doubt that Rust's approach is better. As someone who currently mostly programs in C++, lack of memory safety barely makes my top three concerns. My #1 problem with C++ is that the language is far too complex for (my) comfort, where by "complex" I mean requires too much effort to read and write. That, and build times, have a bigger impact on the correctness of the programs I write than the lack of sound memory safety. Would I be happier if, for a similar cost, I could eliminate all memory safety errors? Sure, which is why, if C++ and Rust were the only low-level languages in existence, I'd rather people used Rust. But I would be happier still if I could solve the first two, and also get some better safety as a cherry-on-top. Memory safety is similarly not the main, and certainly not the only, reason I use languages that have a (tracing) GC when I use them.
- Touche 7y ago
  Just for clarity for anyone reading, the Zig author does not claim that Zig is safe and has in fact said that is unsafe. Could change in the future, but there's no denial about what it is today.
  - pron 7y ago
    There is a difference between safe code, which is the goal, and a safe language (that's a statement the language makes on sound safety guarantees). Using a safe language is definitely one way to write safe code, but it is not necessarily always the best way, and it's certainly not the only way. Zig is not meant to ever be a safe language, but it is very much intended to be a language that helps write safe code. That is what I meant when I said that the two languages have a very different approach to safety.
littlestymaar 7y ago
> reducing bugs of kinds A, B and C -- for a similar cost -- may well be safer. What kind of bugs do your have in mind that Zig would prevent and Rust doesn't ? I can think about several Rust does and Zig doesn't thanks to its afine type system, but I've yet to see a safety feature benefit in Zig.
- pron 7y ago
  Preventing bugs with soundness is not necessarily the best, and certainly not the only, way to reduce bugs. You can reduce bugs by making code easier to read (code review has been empirically shown, time and again, to be the most effective, in terms of cost/benefit, bug reduction technique), and by making code faster to write and to compile, thus leaving more time for tests and other verification techniques. If sound elimination of bugs were the best way to write programs, we'd all be writing in Isabelle, Coq or Idris, except even those of us who do -- in fact, especially those of us who do -- know that it's not the best way to write programs.

by pron 7y ago

pcwalton 7y ago

It's not interesting to talk about a system that might or might not exist in the future. (There is a word for that—"vaporware".) The point is that Zig doesn't even try to prevent UAF now, so you can't say that it's safer than languages that do prevent the problem. > As an example, instead of soundly eliminating bugs of kind A, reducing bugs of kinds A, B and C -- for a similar cost -- may well be safer. Hasn't this essentially been what C++ has been trying for memory safety for decades, without success? The C++ approach has been "smart pointers are good enough, and they prevent several other problems too", and the experience of web browsers (among others) has pretty much definitively shown: no, they really aren't. For memory safety, I would not bet on this approach.

pron 7y ago
> The point is that Zig doesn't even try to prevent UAF now I wouldn't say Zig exists at all right now, but just as it strives to one day be production-ready, it strives to prevent use-after-free. Safety is a stated goal for the language. > Hasn't this essentially been what C++ has been trying for memory safety for decades, without success? No. I'm talking about a mechanism that can detect various errors at runtime, and is turned on or off for various pieces of code and/or for all code at various stages of development. Rust, BTW, doesn't entirely guarantee memory-safety, either, when any unproven unsafe code is used, and even when it isn't (e.g., have you proven LLVM's correctness?). We always make some compromises on soundness; the question is where the sweet-spots are. Software correctness is one area where there are no easy answers and very few obvious ones.
- pcwalton 7y ago
  > No. I'm talking about a mechanism that can detect various errors at runtime, and is turned on or off for various pieces of code and/or for all code at various stages of development What you are describing exists: ASan. We have a pretty good answer to the question "is ASan sufficient to prevent memory safety problems in practice": "no, not really". > Rust, BTW, doesn't entirely guarantee memory-safety, either, when any unproven unsafe code is used, and even when it isn't (e.g., have you proven LLVM's correctness?). We always make some compromises on soundness; the question is where the sweet-spots are. Empirically, Rust's approach has resulted in far fewer memory safety problems than previous approaches like smart pointers and ASan, with only garbage collectors (and restrictive languages with no allocation at all) having similar success in practice. Notice that the working approaches have something important in common: a strong system that, given certain assumptions, guarantees the lack of memory safety problems. Even though those assumptions are never quite satisfied in practice, empirically having those theoretical guarantees seems important. It separates systems that drastically reduce safety problems, such as Rust and GC languages, from those that do so less well, such as ASan and smart pointers. This is why I'm so skeptical of just piling on more mitigations: they're helpful, but we've been piling on mitigations for decades and UAF (for instance) is still a big a problem as ever.
  - pron 7y ago
    > We have a pretty good answer to the question "is ASan sufficient to prevent memory safety problems in practice" That is not the question we're interested in answering, and elimination of all memory errors is no one's ultimate goal, certainly not at any cost. By definition, unsound techniques will let some errors through. The question is which approach leads to an overall safer program for a given effort, and soundness (of properties of interest) always comes at a cost. (also, Zig catches various overflow errors better than ASan) > Empirically, Rust's approach has resulted in far fewer memory safety problems than previous approaches like smart pointers I don't doubt that, and if minimization of memory errors was programmers' primary concern (even in the scope of program correctness or even just security), there would be little doubt that Rust's approach is better. As someone who currently mostly programs in C++, lack of memory safety barely makes my top three concerns. My #1 problem with C++ is that the language is far too complex for (my) comfort, where by "complex" I mean requires too much effort to read and write. That, and build times, have a bigger impact on the correctness of the programs I write than the lack of sound memory safety. Would I be happier if, for a similar cost, I could eliminate all memory safety errors? Sure, which is why, if C++ and Rust were the only low-level languages in existence, I'd rather people used Rust. But I would be happier still if I could solve the first two, and also get some better safety as a cherry-on-top. Memory safety is similarly not the main, and certainly not the only, reason I use languages that have a (tracing) GC when I use them.
Touche 7y ago
Just for clarity for anyone reading, the Zig author does not claim that Zig is safe and has in fact said that is unsafe. Could change in the future, but there's no denial about what it is today.
- pron 7y ago
  There is a difference between safe code, which is the goal, and a safe language (that's a statement the language makes on sound safety guarantees). Using a safe language is definitely one way to write safe code, but it is not necessarily always the best way, and it's certainly not the only way. Zig is not meant to ever be a safe language, but it is very much intended to be a language that helps write safe code. That is what I meant when I said that the two languages have a very different approach to safety.

littlestymaar 7y ago

> reducing bugs of kinds A, B and C -- for a similar cost -- may well be safer. What kind of bugs do your have in mind that Zig would prevent and Rust doesn't ? I can think about several Rust does and Zig doesn't thanks to its afine type system, but I've yet to see a safety feature benefit in Zig.

pron 7y ago
Preventing bugs with soundness is not necessarily the best, and certainly not the only, way to reduce bugs. You can reduce bugs by making code easier to read (code review has been empirically shown, time and again, to be the most effective, in terms of cost/benefit, bug reduction technique), and by making code faster to write and to compile, thus leaving more time for tests and other verification techniques. If sound elimination of bugs were the best way to write programs, we'd all be writing in Isabelle, Coq or Idris, except even those of us who do -- in fact, especially those of us who do -- know that it's not the best way to write programs.