4 ms·

Probably related to the following: https://github.com/ziglang/zig/issues/3180 https://github.com/ziglang/zig/issues/3180

wyldfire 5y ago
Gee, IIUC it looks like it's been addressed by offering a new allocator that's able to detect use-after-free.
- kristoff_it 5y ago
  To be fair this alone is nowhere near what Rust can do for you in terms of safety.
  - wyldfire 5y ago
    But Zig makes this tradeoff intentionally. By design.
    - kllrnohj 5y ago
      "It's intentionally less safe! That's why you should use it!" Zig may strike a better balance than Rust does here, but it seems more like Rust stole its lunch. I don't know why I'd migrate from C/C++ to Zig instead of going all the way to Rust?
      - adamdusty 5y ago
        You wouldn't because you already know Rust. The mental overhead of Zig is essentially zero if you already know C. Also, generics and other syntax is cleaner in my opinion, but that doesn't matter that much.
      - matu3ba 5y ago
        1. Rust doesnt let you safety-check bit-compressed stuff and instead relies on well-formed types during runtime (basically everything that union allows). 2. Graph memory patterns in Rust are completely unsafe. 3. Code might leak and you dont have tooling to check your dependencies. Trusting the test coverage does not help you there with Rust, because Rust tooling is infeasible for testing leaks. 4. CTFE is not easy to track in Rust, so you dont know if certain code may have run-time cost or not. 5. Not all UB during comptime or runtime is (planned to be) checked/checkable https://rust-lang.github.io/rfcs/3016-const-ub.html https://rust-lang.github.io/rfcs/3016-const-ub.html
        roca 5y ago
        1. Unclear what you mean. You can manipulate bits of scalars without writing unsafe code. You can't do bit manipulation of pointers without writing unsafe code. You can write a small library that packs pointers with unsafe code, and then use it safely everywhere you need it. See https://github.com/rpjohnst/dejavu/blob/master/gml/src/vm/value.rs https://github.com/rpjohnst/dejavu/blob/master/gml/src/vm/va... for example. 2. Wrap up the unsafety in a library like petgraph and use it. Or just use petgraph. 3. jemalloc's leak analysis works with Rust, as does Heaptrack. 4. With const generics it's trivial to pass a value through a const generic parameter to ensure it was evaluated at compile time. Right now that only works for scalars but that limitation will be relaxed later. 5. Most Rust code is safe code which is free from UB. Dynamic checks of all unsafe-code UB is infeasible. So what? But anyway, none of these are reasons to use Zig.
        matu3ba 5y ago
        1. Union is used to dynamically interpret data of an underlying buffer or memory segment. You will find union as being inherently unsafe in Rust: https://doc.rust-lang.org/reference/items/unions.html https://doc.rust-lang.org/reference/items/unions.html 2. petgraph looks like they only allow allocating and freeing in the same order and no deallocating of segments (think of a graph pointing to another graph) dynamically. So even if you wrap it, you cant arbitrarily deallocate and allocate things upon semantic conditions. 3. It would be more helpful to use static analysis or making functionality with potential leaks similar to have this information on code review instead of trying to test all code paths. 4. True. I think that works then. Looks like between Rust and Zig "const equals comptime". 5. "Dynamic checks of all unsafe-code UB is infeasible." It is only infeasible, if you dont have an idea on the memory model during comptime. The RFC also writes "In particular, this would mean we need to decide on an aliasing model before permitting raw pointers in CTFE.", because Rust is not settled on that yet. On the upside, this speeds up compilation, lol.
        roca 5y ago
        1. f32::from_bits/to_bits etc allow safe bit-casting between primitive types. Libraries like safe-transmute wrap up unsafe array pointer casts into safe APIs. Rust has great tools to address the use-cases where C would use unions. 2. The big picture here is that for graphs and other data structures, you figure out a safe API for the data structure and write a library that hides the unsafety behind that API (or just use a library that someone else already wrote). You get a clean separation between a small amount of unsafe code and a large amount of safe code. This is the Zen of Rust and it's why "Rust can't express <XYZ> safely" is almost never an important issue in practice. 3. Rust's ownership and determinstic destructors mean you really have to go out of your way to create a memory leak; "just forgot to free it" doesn't happen. A memory leak has to be something nontrivial like a global data structure that is added to but not removed from, or a reference-count cycle that isn't broken. There aren't really good automatic static techniques for detecting these AFAIK (and I have a background in static program analysis) --- you would need something that models heap states over time, like shape analysis, which doesn't scale. As far as I can tell Rust at least as strong as any other real-world non-GC language at preventing memory leaks, certainly stronger than Zig which lacks ownership and destructors. 5. This is an issue I don't know much about so I'll leave it. FWIW the endgame for unsafe code in Rust is formal semantics for unsafe code, proof obligations that guarantee the unsafe code preserves Rust safety invariants, and proof-assistant tools that let you formally prove the safety of your "unsafe" code. There's a lot of work to get there but that work is well underway.
  - ngrilly 5y ago
    Any plans to go one step further towards memory safety (and even better data race freedom)? Maybe using ARC when the overhead is acceptable (like Swift), it static analysis is not possible due to the type system not supporting the concepts of ownership, borrowing, lifetimes and so on? Zig is super exciting, but without a GC or Rust type system, I’m worried about going “back” to a language where I have to think about memory leaks, use after free and so on.
    - matu3ba 5y ago
      As of now the tradeoff of Rust's type system is that code may leak memory and you may need to investigate all occurrences to fix it, because there is no tooling yet (testing everything is infeasible). You can have either extensive static analysis or fast compile times. Tracking ownership down to semantic analysis (where type layouts are in resolved form) requires adjusting and slowing down the complete compiler.
      - ngrilly 5y ago
        Did you mean Zig? I don’t understand how Rust code can leak memory?
        steveklabnik 5y ago
        https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...
- pjmlp 5y ago
  So can debugging tools for C and C++ since late 1990's, zero progress there.

wyldfire 5y ago

Gee, IIUC it looks like it's been addressed by offering a new allocator that's able to detect use-after-free.

kristoff_it 5y ago
To be fair this alone is nowhere near what Rust can do for you in terms of safety.
- wyldfire 5y ago
  But Zig makes this tradeoff intentionally. By design.
  - kllrnohj 5y ago
    "It's intentionally less safe! That's why you should use it!" Zig may strike a better balance than Rust does here, but it seems more like Rust stole its lunch. I don't know why I'd migrate from C/C++ to Zig instead of going all the way to Rust?
    - adamdusty 5y ago
      You wouldn't because you already know Rust. The mental overhead of Zig is essentially zero if you already know C. Also, generics and other syntax is cleaner in my opinion, but that doesn't matter that much.
    - matu3ba 5y ago
      1. Rust doesnt let you safety-check bit-compressed stuff and instead relies on well-formed types during runtime (basically everything that union allows). 2. Graph memory patterns in Rust are completely unsafe. 3. Code might leak and you dont have tooling to check your dependencies. Trusting the test coverage does not help you there with Rust, because Rust tooling is infeasible for testing leaks. 4. CTFE is not easy to track in Rust, so you dont know if certain code may have run-time cost or not. 5. Not all UB during comptime or runtime is (planned to be) checked/checkable https://rust-lang.github.io/rfcs/3016-const-ub.html https://rust-lang.github.io/rfcs/3016-const-ub.html
      - roca 5y ago
        1. Unclear what you mean. You can manipulate bits of scalars without writing unsafe code. You can't do bit manipulation of pointers without writing unsafe code. You can write a small library that packs pointers with unsafe code, and then use it safely everywhere you need it. See https://github.com/rpjohnst/dejavu/blob/master/gml/src/vm/value.rs https://github.com/rpjohnst/dejavu/blob/master/gml/src/vm/va... for example. 2. Wrap up the unsafety in a library like petgraph and use it. Or just use petgraph. 3. jemalloc's leak analysis works with Rust, as does Heaptrack. 4. With const generics it's trivial to pass a value through a const generic parameter to ensure it was evaluated at compile time. Right now that only works for scalars but that limitation will be relaxed later. 5. Most Rust code is safe code which is free from UB. Dynamic checks of all unsafe-code UB is infeasible. So what? But anyway, none of these are reasons to use Zig.
        matu3ba 5y ago
        1. Union is used to dynamically interpret data of an underlying buffer or memory segment. You will find union as being inherently unsafe in Rust: https://doc.rust-lang.org/reference/items/unions.html https://doc.rust-lang.org/reference/items/unions.html 2. petgraph looks like they only allow allocating and freeing in the same order and no deallocating of segments (think of a graph pointing to another graph) dynamically. So even if you wrap it, you cant arbitrarily deallocate and allocate things upon semantic conditions. 3. It would be more helpful to use static analysis or making functionality with potential leaks similar to have this information on code review instead of trying to test all code paths. 4. True. I think that works then. Looks like between Rust and Zig "const equals comptime". 5. "Dynamic checks of all unsafe-code UB is infeasible." It is only infeasible, if you dont have an idea on the memory model during comptime. The RFC also writes "In particular, this would mean we need to decide on an aliasing model before permitting raw pointers in CTFE.", because Rust is not settled on that yet. On the upside, this speeds up compilation, lol.
        roca 5y ago
        1. f32::from_bits/to_bits etc allow safe bit-casting between primitive types. Libraries like safe-transmute wrap up unsafe array pointer casts into safe APIs. Rust has great tools to address the use-cases where C would use unions. 2. The big picture here is that for graphs and other data structures, you figure out a safe API for the data structure and write a library that hides the unsafety behind that API (or just use a library that someone else already wrote). You get a clean separation between a small amount of unsafe code and a large amount of safe code. This is the Zen of Rust and it's why "Rust can't express <XYZ> safely" is almost never an important issue in practice. 3. Rust's ownership and determinstic destructors mean you really have to go out of your way to create a memory leak; "just forgot to free it" doesn't happen. A memory leak has to be something nontrivial like a global data structure that is added to but not removed from, or a reference-count cycle that isn't broken. There aren't really good automatic static techniques for detecting these AFAIK (and I have a background in static program analysis) --- you would need something that models heap states over time, like shape analysis, which doesn't scale. As far as I can tell Rust at least as strong as any other real-world non-GC language at preventing memory leaks, certainly stronger than Zig which lacks ownership and destructors. 5. This is an issue I don't know much about so I'll leave it. FWIW the endgame for unsafe code in Rust is formal semantics for unsafe code, proof obligations that guarantee the unsafe code preserves Rust safety invariants, and proof-assistant tools that let you formally prove the safety of your "unsafe" code. There's a lot of work to get there but that work is well underway.
- ngrilly 5y ago
  Any plans to go one step further towards memory safety (and even better data race freedom)? Maybe using ARC when the overhead is acceptable (like Swift), it static analysis is not possible due to the type system not supporting the concepts of ownership, borrowing, lifetimes and so on? Zig is super exciting, but without a GC or Rust type system, I’m worried about going “back” to a language where I have to think about memory leaks, use after free and so on.
  - matu3ba 5y ago
    As of now the tradeoff of Rust's type system is that code may leak memory and you may need to investigate all occurrences to fix it, because there is no tooling yet (testing everything is infeasible). You can have either extensive static analysis or fast compile times. Tracking ownership down to semantic analysis (where type layouts are in resolved form) requires adjusting and slowing down the complete compiler.
    - ngrilly 5y ago
      Did you mean Zig? I don’t understand how Rust code can leak memory?
      - steveklabnik 5y ago
        https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...
pjmlp 5y ago
So can debugging tools for C and C++ since late 1990's, zero progress there.