4 ms·
> 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/uns
by kbd 5y 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 5y agoOut 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?