]> git.lizzy.rs Git - rust.git/commitdiff
Clarify docs for Read::read's return value
authorJannis Harder <me@jix.one>
Mon, 8 Mar 2021 10:58:05 +0000 (11:58 +0100)
committerJannis Harder <me@jix.one>
Thu, 18 Mar 2021 21:52:46 +0000 (22:52 +0100)
library/std/src/io/mod.rs

index 17002e3b8602d7eb2c45bbe1d8f7a48bb2941137..6abb300054af8c22516eb93200324a46941f606c 100644 (file)
@@ -514,8 +514,8 @@ pub trait Read {
     /// waiting for data, but if an object needs to block for a read and cannot,
     /// it will typically signal this via an [`Err`] return value.
     ///
-    /// If the return value of this method is [`Ok(n)`], then it must be
-    /// guaranteed that `0 <= n <= buf.len()`. A nonzero `n` value indicates
+    /// If the return value of this method is [`Ok(n)`], then implementations must
+    /// guarantee that `0 <= n <= buf.len()`. A nonzero `n` value indicates
     /// that the buffer `buf` has been filled in with `n` bytes of data from this
     /// source. If `n` is `0`, then it can indicate one of two scenarios:
     ///
@@ -529,6 +529,11 @@ pub trait Read {
     /// This may happen for example because fewer bytes are actually available right now
     /// (e. g. being close to end-of-file) or because read() was interrupted by a signal.
     ///
+    /// As this trait is safe to implement, callers cannot rely on `n <= buf.len()` for safety.
+    /// Extra care needs to be taken when `unsafe` functions are used to access the read bytes.
+    /// Callers have to ensure that no unchecked out-of-bounds accesses are possible even if
+    /// `n > buf.len()`.
+    ///
     /// No guarantees are provided about the contents of `buf` when this
     /// function is called, implementations cannot rely on any property of the
     /// contents of `buf` being true. It is recommended that *implementations*