6 ms·

Zig seems to be doing a lot of things right (just like Rust did). Sadly I think that their disregard for safety (the manual states that dangling pointers is th

Zig seems to be doing a lot of things right (just like Rust did). Sadly I think that their disregard for safety (the manual states that dangling pointers is the developers problem) kinda makes it a no-starter for many people. I personally consider possible information breach far worse than a crash or runtime stall.

kbd 6y ago
> disregard for safety Your opinion seems to be that any future systems language that doesn't implement a heavy Rust-style borrow checker and explicit safe/unsafe modes "disregards safety"? Zig does have a lot of checks, such as bounds checking[1]. There are also test modes that help catch errors. I don't know what you're referring to about "information breach". > The manual states that dangling pointers is the developers problem... In a systems language where you can cast an int to a pointer: const ptr = @intToPtr(*i32, 0xdeadbee0); or where you have to manually manage memory, what else do you expect? Zig made the design choice to not split the world into safe vs unsafe. It seems a bit unwarranted to say that because they didn't make the same design choices Rust did that they have a "disregard for safety". [1] https://ziglang.org/documentation/master/#Index-out-of-Bounds https://ziglang.org/documentation/master/#Index-out-of-Bound...
- whizzter 6y ago
  Out of bounds check is definitely a responsible start. As for the exact methods I'm not really partial to anything (Be it borrow-checker,gc,compiler-time-analysis,etc) but we've seen time and time out of bounds(handled by Zig atleast), UAF and other issues be exploited so having "safe" defaults for the majority of code isn't something I think we should skip on, especially if it's a "systems language" since the exploitation surface will end up everywhere. The Rust borrow checker can probably feel cludgy at times, and in many ways it's a result of creating a scheme that is verifiasble. Since Zig already has comptime I guess having expand compile time capabilties to analyze for common UAF conditions,etc shouldn't be unfeasible?
dnautics 6y ago
> Sadly I think that their disregard for safety I wouldn't call it a disregard. Zig's approach is to give you easy and automatic tools to detect and handle most of those memory safety problems in its language-first-class test system, which you can think of as a carrot to get you to write tests.
- whizzter 6y ago
  Automatic tools is definitevly a plus, I guess the only thing is that adversaries can possibly see what tests missed (UAF often involves code behavior differences between modules).

kbd 6y ago

> disregard for safety Your opinion seems to be that any future systems language that doesn't implement a heavy Rust-style borrow checker and explicit safe/unsafe modes "disregards safety"? Zig does have a lot of checks, such as bounds checking[1]. There are also test modes that help catch errors. I don't know what you're referring to about "information breach". > The manual states that dangling pointers is the developers problem... In a systems language where you can cast an int to a pointer: const ptr = @intToPtr(*i32, 0xdeadbee0); or where you have to manually manage memory, what else do you expect? Zig made the design choice to not split the world into safe vs unsafe. It seems a bit unwarranted to say that because they didn't make the same design choices Rust did that they have a "disregard for safety". [1] https://ziglang.org/documentation/master/#Index-out-of-Bounds https://ziglang.org/documentation/master/#Index-out-of-Bound...

whizzter 6y ago
Out of bounds check is definitely a responsible start. As for the exact methods I'm not really partial to anything (Be it borrow-checker,gc,compiler-time-analysis,etc) but we've seen time and time out of bounds(handled by Zig atleast), UAF and other issues be exploited so having "safe" defaults for the majority of code isn't something I think we should skip on, especially if it's a "systems language" since the exploitation surface will end up everywhere. The Rust borrow checker can probably feel cludgy at times, and in many ways it's a result of creating a scheme that is verifiasble. Since Zig already has comptime I guess having expand compile time capabilties to analyze for common UAF conditions,etc shouldn't be unfeasible?

dnautics 6y ago

> Sadly I think that their disregard for safety I wouldn't call it a disregard. Zig's approach is to give you easy and automatic tools to detect and handle most of those memory safety problems in its language-first-class test system, which you can think of as a carrot to get you to write tests.

whizzter 6y ago
Automatic tools is definitevly a plus, I guess the only thing is that adversaries can possibly see what tests missed (UAF often involves code behavior differences between modules).