| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
previous code was perfectly sound because of MaybeUninit,
but it did waste cycles on copying memory that is
known to be uninitialized.
|
|
|
|
r=Mark-Simulacrum
doc: clarify that consume can be called after BufReader::peek
tracking issue #128405
|
|
|
|
Buffer::read_more() is supposed to refill the buffer without discarding
its contents, which are in the range `pos .. filled`.
It mistakenly borrows the range `pos ..`, fills that, and then
increments `filled` by the amount read. This overwrites the buffer's
existing contents and sets `filled` to a too-large value that either
exposes uninitialized bytes or walks off the end of the buffer entirely.
This patch makes it correctly fill only the unfilled portion of the
buffer, which should maintain all the type invariants and fix the test
failure introduced in commit b1196717fcb.
|
|
This patch makes BufReader::peek()'s doctest call read_more() to refill
the buffer before the inner reader hits EOF. This exposes a bug in
read_more() that causes an out-of-bounds slice access and segfault.
|
|
|
|
Also update the tests to avoid testing implementation details.
|
|
|
|
|
|
Fix `read_buf` uses in `std`
Following lib-team decision here: https://github.com/rust-lang/rust/issues/78485#issuecomment-2122992314
Guard against the pathological behavior of both returning an error and performing a read.
|
|
|
|
|
|
|
|
properly handle EOF in BufReader::peek
previously this would cause an infinite loop due to it being unable to read `n` bytes.
|
|
|
|
previously this would cause an infinite loop due to it being
unable to read `n` bytes.
|
|
|
|
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
Many tiny changes to stdlib doc comments to make them consistent (for example
"Returns foo", rather than "Return foo", per RFC1574), adding missing periods, paragraph
breaks, backticks for monospace style, and other minor nits.
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text
|
|
|
|
|
|
This makes their intent and expected location clearer. We see some
examples where these comments were not clearly separate from `use`
declarations, which made it hard to understand what the comment is
describing.
|
|
r=joshtriplett
std: use `stream_position` where applicable
by replacing `seek(SeekFrom::Current(0))` calls
|
|
|
|
Specialize many implementations of `Read::read_buf_exact`
This makes all implementations of `Read` that have a specialized `read_exact` implementation also have one for `read_buf_exact`.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
impl From<TryReserveError> for io::Error
There's an obvious mapping between these two errors, and it makes I/O code less noisy.
I've chosen to use simple `ErrorKind::OutOfMemory` `io::Error`, without keeping `TryReserveError` for the `source()`, because:
* It matches current uses in libstd,
* `ErrorData::Custom` allocates, which is a risky proposition for handling OOM errors specifically.
* Currently `TryReserveError` has no public fields/methods, so it's usefulness is limited. How allocators should report errors, especially custom and verbose ones is still an open question.
Just in case I've added note in the doccomment that this may change.
The compiler forced me to declare stability of this impl. I think this implementation is simple enough that it doesn't need full-blown stabilization period, and I've marked it for the next release, but of course I can adjust the attribute if needed.
|
|
Some implementations of `Write::write_vectored` in the standard
library (`BufWriter`, `LineWriter`, `Stdout`, `Stderr`) check all
buffers to calculate the total length. This is O(n) over the number of
buffers.
It's common that only a limited number of buffers is written at a
time (e.g. 1024 for `writev(2)`). `write_vectored_all` will then call
`write_vectored` repeatedly, leading to a runtime of O(n²) over the
number of buffers.
The fix is to only calculate as much as needed if it's needed.
|
|
|
|
Currently all architecture-specific memchr code is only used in
`std::io`. Most of the actual `memchr` capacity exposed to the user
through the slice API is instead implemented in core::slice::memchr.
Hence this commit deletes memchr from std::sys[_common] and replace
calls to it by calls to core::slice::memchr functions. This deletes
(r)memchr from the list of symbols linked to libc.
|
|
|
|
by replacing `seek(SeekFrom::Current(0))` calls
|
|
|
|
Add Seek::seek_relative
The `BufReader` struct has a `seek_relative` method because its `Seek::seek` implementation involved dumping the internal buffer (https://github.com/rust-lang/rust/issues/31100).
Unfortunately, there isn't really a good way to take advantage of that method in generic code. This PR adds the same method to the main `Seek` trait with the straightforward default method, and an override for `BufReader` that calls its implementation.
_Also discussed in [this](https://internals.rust-lang.org/t/add-seek-seek-relative/19546) internals.rust-lang.org thread._
|
|
This reduces the runtime for a simple program using `Bytes::next` to
iterate through a file from 220ms to 70ms on my Linux box.
|
|
|
|
|
|
Fix incorrect documented default bufsize in bufreader/writer
|
|
previously it was only able to use BufWriter. This was due to a limitation in the
BufReader generics that prevented specialization. This change works around the issue
by using `where Self: Read` instead of `where I: Read`. This limits our options, e.g.
we can't access BufRead methods, but it happens to work out if we rely on some
implementation details.
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
`ptr::read` takes `*const T` so `&mut` is not necessary.
|
