4 ms·

You were correct about the lack of billion dollar mistake in Zig, once I'd decided to list some "C replacement" languages not just C and C++ I should have eithe

You were correct about the lack of billion dollar mistake in Zig, once I'd decided to list some "C replacement" languages not just C and C++ I should have either checked they all make exactly this mistake (Odin does, Zig does not) or removed that part of my comment. However actually in practice for this nVidia bug Zig's "defer" is just irrelevant, which is why nVidia's "fix" doesn't attempt the most similar C equivalent strategy and instead now performs a heap allocation (and thus free) on the happy path. There's a kernel Oops, likely in someone else's code. When that happens our stack goes away. In Rust they can (I don't happen to know if they do in Rust for Linux but it is commonly used in some types of application) recover from disasters and unwind the stack before it's gone, such as removing the threadState from that global state. In Zig that's prohibited by the language design, all panics are fatal.

davemp 1y ago
What a crap, disingenuous argument. A kernel oops isn’t a panic at least however zig or rust defines a panic. So zig saying things about panics don’t apply here. Rust fails here the same exact way if drop semantics aren’t upheld (they aren’t afaik). Also Rust’s soundness goes immediately out the window if UB happens in unsafe code. So immediately when a kernel Oops happens safety is moot point. I’m not sure if Zig has a clean way to kill a thread, unwind the stack, and run deferred code. Zig is a pre-1.0 language after all so it’s allowed to be missing features.
- tialaramex 1y ago
  > I’m not sure if Zig has a clean way to kill a thread, unwind the stack, and run deferred code. Zig deliberately only has fatal panic. This isn't a "missing feature" it's intentional