Hacker News Reader

> 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.

View on HN

The 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.

I'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.

The write is fine, but the subsequent read isn't (unless you know that the write happened, which the Rust compiler doesn't).

Reply on news.ycombinator.com