4 ms·
The problem isn't undefined behavior per se; I was using it as an example for strncpy. Rust is a no - in fact, the goal of (safe) Rust is to eliminate undefined
by Cyph0n 9mo ago
The problem isn't undefined behavior per se; I was using it as an example for strncpy. Rust is a no - in fact, the goal of (safe) Rust is to eliminate undefined behavior. Zig on the other hand I don't know about.
In general, I see two issues at play here:
1. C relies heavily on unsized pointers (vs. fat pointers), which is why strncpy_s had to "break" strncpy in order to improve bounds checks.
2. strncpy memory aliasing restrictions are not encoded in the API and can only be conveyed through docs. This is a footgun.
For (1), Rust APIs of this type operate on sized slices, or in the case of strings, string slices. Zig defines strings as sized byte slices.
For (2), Rust enforces this invariant via the borrow checker by disallowing (at compile-time) a shared slice reference that points to an overlapping mutable slice reference. In other words, an API like this is simply not possible to define in (safe) Rust, which means you (as the user) do not need to pore over the docs for each stdlib function you use looking for memory-related footguns.
- loeg 9mo ago> For (2), Rust enforces this invariant via the borrow checker by disallowing (at compile-time) a shared slice reference that points to an overlapping mutable slice reference. At least the last time I cared about this, the borrow checker wouldn't allow mutable and immutable borrows from the same underlying object, even if they did not overlap. (Which is more restrictive, in an obnoxious way.)
- Cyph0n 9mo agoDo you mean borrows for different fields of a struct? If so, that’s handled today - it’s sometimes called “splitting borrows”: https://doc.rust-lang.org/nomicon/borrow-splitting.html https://doc.rust-lang.org/nomicon/borrow-splitting.html
- loeg 9mo agoNot exactly -- independent subranges of the same range (as would be relevant to something like memcpy/memmove/strcpy). E.g., https://godbolt.org/z/YhGajnhEG https://godbolt.org/z/YhGajnhEG It's mentioned later in the same article you shared above.
- Cyph0n 9mo agoGotcha. There is a split_at_mut method that splits a mutable slice reference into two. That doesn’t address the problem you had, but I think that’s best you can do with safe Rust.
- loeg 9mo agoYeah. It just isn't something the borrow checker natively understands.
- oneshtein 9mo agofn f() { let mut v = vec![1, 2, 3, 4, 5]; let (header, tail) = v.split_at_mut(1); b(&header[0], &mut tail[0]); }
- loeg 9mo agosplit_at_mut is just unsafe code (and sibling comment mentioned it hours before you did). The borrow checker doesn't natively understand that.
- Cyph0n 9mo agoIt is safe btw. The difference is that it returns two mutable references vs. one shared ref and one mutable ref. But as they noted, a mutable ref can always be “downgraded” into a shared ref.
- loeg 9mo agoThe implementation is unsafe, as I said: > split_at_mut is just unsafe code (and sibling comment mentioned it hours before you did). The borrow checker doesn't natively understand that. https://doc.rust-lang.org/src/core/slice/mod.rs.html#2086 https://doc.rust-lang.org/src/core/slice/mod.rs.html#2086
- Cyph0n 9mo ago