Enhance the documentation of BufReader for potential data loss #65554
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @KodrAus (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
rust-highfive
added
the
S-waiting-on-review
src/libstd/io/buffered.rs
Outdated
| @@ -24,7 +24,8 @@ use crate::memchr; | |||
| /// | |||
| /// When the `BufReader<R>` is dropped, the contents of its buffer will be | |||
| /// discarded. Creating multiple instances of a `BufReader<R>` on the same | |||
| /// stream can cause data loss. | |||
| /// stream can cause data loss, as well as reading from the underlying reader | |||
There was a problem hiding this comment.
How about:
Reading from the underlying reader after unwrapping the BufReader<R> with BufReader::into_inner can also cause data loss.
|
@gliderkite Ah, would you be able to rebase your PR on top of |
hdhoang
added
S-waiting-on-author
|
ping from triage @gliderkite, could you rebase as suggested above? It would really help with reviewing. Thanks! |
gliderkite
force-pushed
the
bufreader-doc-enhance
branch
from
6578cfa to
5b5196a
Compare
Rebased, sorry about the confusion. |
|
@bors r+ rollup |
|
📌 Commit 5b5196a has been approved by |
bors
added
S-waiting-on-bors
…=KodrAus Enhance the documentation of BufReader for potential data loss This is (IMO) and enhancement of the `std::io::BufReader` documentation, that aims to highlight how relatively easy is to end up with data loss when improperly using an instance of this class. This is following the issue I had figuring out why my application was loosing data, because I focused my attention on the word *multiple instances* of `BufReader` in its `struct` documentation, even if I ever only had one instance. Link to the issue: tokio-rs/tokio#1662
Rollup of 8 pull requests Successful merges: - #65554 (Enhance the documentation of BufReader for potential data loss) - #65580 (Add `MaybeUninit` methods `uninit_array`, `slice_get_ref`, `slice_get_mut`) - #66049 (consistent handling of missing sysroot spans) - #66056 (rustc_metadata: Some reorganization of the module structure) - #66123 (No more hidden elements) - #66157 (Improve math log documentation examples) - #66165 (Ignore these tests ,since the called commands doesn't exist in VxWorks) - #66190 (rustc_target: inline abi::FloatTy into abi::Primitive.) Failed merges: - #66188 (`MethodSig` -> `FnSig` & Use it in `ItemKind::Fn`) r? @ghost
This is (IMO) and enhancement of the
std::io::BufReaderdocumentation, that aims to highlight how relatively easy is to end up with data loss when improperly using an instance of this class.This is following the issue I had figuring out why my application was loosing data, because I focused my attention on the word multiple instances of
BufReaderin itsstructdocumentation, even if I ever only had one instance.Link to the issue: tokio-rs/tokio#1662