2 ms·
> it's because the Rust compiler cannot yet statically verify there's no undefined behavior in this case Uh... yes it can. It's a memory write to the uninitia
by ajross 2y ago
> it's because the Rust compiler cannot yet statically verify there's no undefined behavior in this case
Uh... yes it can. It's a memory write to the uninitialized region. Writes are not undefined, nor unsafe, and never have been. They aren't in C, they aren't in hardware. Writes are fine.
The bug here is API design, not verification constraints.
- GrantMoyer 2y agoThe issue isn't writes to uninitialized memory, it's reads from uninitialzed memory. The compiler doesn't know how much of the buffer `read` writes. The docs say it returns a unsigned integer with how many bytes it wrote, so a programmer can know the later read from `buffer[0..num_bytes_written]` is valid, but the compiler doesn't know what the number returned from `read` represents, so from the compiler's point of view, the whole buffer needs to be initialized regardless of what read does for reads from it to be valid. That means it has to be initialized before it's passed to read, otherwise the compiler can't prove the elements which are later read from the buffer are initialized.
- ajross 2y agoI'm basically going to give up and declare victory. You're saying more or less exactly what I said above and that you took issue with, which is that the fundamental problem here is one of API design (Rust's kinda sucks) and not the safety of the underlying primitive being abstracted, which has never been at issue. And certainly nothing about undefined behavior, given that it's 100% well defined.
- lmm 2y agoThe write is fine, but the subsequent read isn't (unless you know that the write happened, which the Rust compiler doesn't).