| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
* For read and read_buf, only the front slice of a discontiguous
VecDeque is copied. The VecDeque is advanced after reading, making any
back slice available for reading with a second call to Read::read(_buf).
* For write, the VecDeque always appends the entire slice to the end,
growing its allocation when necessary.
|
|
|
|
This allows using `ReadBuf` in a builder-like style and to setup a `ReadBuf` and
pass it to `read_buf` in a single expression, e.g.,
```
// With this PR:
reader.read_buf(ReadBuf::uninit(buf).assume_init(init_len))?;
// Previously:
let mut buf = ReadBuf::uninit(buf);
buf.assume_init(init_len);
reader.read_buf(&mut buf)?;
```
Signed-off-by: Nick Cameron <nrc@ncameron.org>
|
|
Stabilize Stdin::lines.
Closes https://github.com/rust-lang/rust/issues/87096
Fcp completed here: https://github.com/rust-lang/rust/issues/87096#issuecomment-1028792980
|
|
|
|
Strict Provenance MVP
This patch series examines the question: how bad would it be if we adopted
an extremely strict pointer provenance model that completely banished all
int<->ptr casts.
The key insight to making this approach even *vaguely* pallatable is the
ptr.with_addr(addr) -> ptr
function, which takes a pointer and an address and creates a new pointer
with that address and the provenance of the input pointer. In this way
the "chain of custody" is completely and dynamically restored, making the
model suitable even for dynamic checkers like CHERI and Miri.
This is not a formal model, but lots of the docs discussing the model
have been updated to try to the *concept* of this design in the hopes
that it can be iterated on.
See #95228
|
|
Document Linux kernel handoff in std::io::copy and std::fs::copy
|
|
|
|
|
|
Some things like the unwinders and system APIs are not fully conformant,
this only covers a lot of low-hanging fruit.
|
|
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
|
|
|
|
|
|
|
|
|
|
r=dtolnay
Consistently present absent stdio handles on Windows as NULL handles.
This addresses #90964 by making the std API consistent about presenting
absent stdio handles on Windows as NULL handles. Stdio handles may be
absent due to `#![windows_subsystem = "windows"]`, due to the console
being detached, or due to a child process having been launched from a
parent where stdio handles are absent.
Specifically, this fixes the case of child processes of parents with absent
stdio, which previously ended up with `stdin().as_raw_handle()` returning
`INVALID_HANDLE_VALUE`, which was surprising, and which overlapped with an
unrelated valid handle value. With this patch, `stdin().as_raw_handle()`
now returns null in these situation, which is consistent with what it
does in the parent process.
And, document this in the "Windows Portability Considerations" sections of
the relevant documentation.
|
|
Implement `Write for Cursor<[u8; N]>`, plus `A: Allocator` cursor support
This implements `Write for Cursor<[u8; N]>`, and also adds support for generic `A: Allocator` in `Box` and `Vec` cursors.
This was inspired by a user questioning why they couldn't write a `Cursor<[u8; N]>`:
https://users.rust-lang.org/t/why-vec-and-not-u8-makes-cursor-have-write/68210
Related history:
- #27197 switched `AsRef<[u8]>` for reading and seeking
- #67415 tried to use `AsMut<[u8]>` for writing, but did not specialize `Vec`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This updates the standard library's documentation to use the new syntax. The
documentation is worthwhile to update as it should be more idiomatic
(particularly for features like this, which are nice for users to get acquainted
with). The general codebase is likely more hassle than benefit to update: it'll
hurt git blame, and generally updates can be done by folks updating the code if
(and when) that makes things more readable with the new format.
A few places in the compiler and library code are updated (mostly just due to
already having been done when this commit was first authored).
|
|
This addresses #90964 by making the std API consistent about presenting
absent stdio handles on Windows as NULL handles. Stdio handles may be
absent due to `#![windows_subsystem = "windows"]`, due to the console
being detached, or due to a child process having been launched from a
parent where stdio handles are absent.
Specifically, this fixes the case of child processes of parents with absent
stdio, which previously ended up with `stdin().as_raw_handle()` returning
`INVALID_HANDLE_VALUE`, which was surprising, and which overlapped with an
unrelated valid handle value. With this patch, `stdin().as_raw_handle()`
now returns null in these situation, which is consistent with what it
does in the parent process.
And, document this in the "Windows Portability Considerations" sections of
the relevant documentation.
|
|
Make regular stdio lock() return 'static handles
This also deletes the unstable API surface area previously added to expose this
functionality on new methods rather than built into the current set.
Closes #86845 (tracking issue for unstable API needed without this)
r? ``````@dtolnay`````` to kick off T-libs-api FCP
|
|
|
|
|
|
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
|
|
|
|
|
|
|
|
This also deletes the unstable API surface area previously added to expose this
functionality on new methods rather than built into the current set.
|
|
|
|
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
|
|
|
|
quite accurate anymore
|
|
|
|
|
|
|
|
Co-authored-by: the8472 <the8472@users.noreply.github.com>
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
|
|
|
|
|
|
`impl Display for io::ErrorKind`
This avoids having to convert from `ErrorKind` to `Error` just to print the error message.
|
|
|
|
|
|
|
