-
Notifications
You must be signed in to change notification settings - Fork 302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idea: BytesMut::from_reader #770
Comments
The proposed implementation is incorrect. The reader could read the uninitialized bytes, which is not allowed. |
That's a good point. It would be nice if there was a way to explicitly copy into a slice of uninit to ensure that the read impl doesn't do anything naughty. I suppose I could rewrite the read_exact logic in this function to avoid the read impl being able to read the buf. Def open to any advice! And also to be clear, it's only UB if the read impl actually reads from the buffer right? If the impl only copies to the buffer there is no UB. |
There is a https://doc.rust-lang.org/std/io/trait.Read.html#method.read_buf_exact method:
However, it's nightly: rust-lang/rust#78485 |
Reading into uninitialized bytes requires the unstable API that marvin metioned. However, in async code, Tokio's |
Is there any interest in a convenience method for initializing a BytesMut from a
std::io::Reader
with an explicit length? Something like this:The rational is to allow
forbid(unsafe)
crates to safely initialize a BytesMut object from a reader given a known length. I'm using this technique in this PR on thefjall/value-log
project to improve performance over usingBytesMut::zeroed
by roughly 50%: https://github.com/fjall-rs/value-log/pull/22/filesThe main issue I see with this request/idea is that read_exact can be dangerous to use due to it internally blocking forever on reads. In fjall's case it makes sense, but I could see this not being the best choice in many cases. But I figured it would be worth bringing up and seeing what the community thinks!
In other news, huge thanks to the maintainers and contributers of bytes for such a great project!
The text was updated successfully, but these errors were encountered: