| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
When working with an arbitrary reader or writer, code that uses vectored
operations may end up being slower than code that copies into a single
buffer when the underlying reader or writer doesn't actually support
vectored operations. These new methods allow you to ask the reader or
witer up front if vectored operations are efficiently supported.
Currently, you have to use some heuristics to guess by e.g. checking if
the read or write only accessed the first buffer. Hyper is one concrete
example of a library that has to do this dynamically:
https://github.com/hyperium/hyper/blob/0eaf304644a396895a4ce1f0146e596640bb666a/src/proto/h1/io.rs#L582-L594
|
|
The ioctl(FIONBIO) method of setting a file descriptor to be
non-blocking does not notify the underlying resource in the same way
that fcntl(F_SETFL, O_NONBLOCK) does on illumos and Solaris.
|
|
Co-Authored-By: Jason King <jason.brian.king@gmail.com>
Co-Authored-By: Joshua M. Clulow <jmc@oxide.computer>
|
|
Fix double-free and undefined behaviour in libstd::syn::unix::Thread::new
While working on concurrency support for Miri, I found that the `libstd::syn::unix::Thread::new` method has two potential problems: double-free and undefined behaviour.
**Double-free** could occur if the following events happened (credit for pointing this out goes to @RalfJung):
1. The call to `pthread_create` successfully launched a new thread that executed to completion and deallocated `p`.
2. The call to `pthread_attr_destroy` returned a non-zero value causing the `assert_eq!` to panic.
3. Since `mem::forget(p)` was not yet executed, the destructor of `p` would be executed and cause a double-free.
As far as I understand, this code also violates the stacked-borrows aliasing rules and thus would result in **undefined behaviour** if these rules were adopted. The problem is that the ownership of `p` is passed to the newly created thread before the call to `mem::forget`. Since the call to `mem::forget` is still a call, it counts as a use of `p` and triggers UB.
This pull request changes the code to use `mem::ManuallyDrop` instead of `mem::forget`. As a consequence, in case of a panic, `p` would be potentially leaked, which while undesirable is probably better than double-free or undefined behaviour.
|
|
|
|
|
|
|
|
|
|
use is_empty() instead of len comparison (clippy::len_zero)
use if let instead of while let loop that never loops (clippy::never_loop)
remove redundant returns (clippy::needless_return)
remove redundant closures (clippy::redundant_closure)
use if let instead of match and wildcard pattern (clippy::single_match)
don't repeat field names redundantly (clippy::redundant_field_names)
|
|
Use getentropy(2) on macos
resolves #70179
|
|
Fix abort-on-eprintln during process shutdown
This commit fixes an issue where if `eprintln!` is used in a TLS
destructor it can accidentally cause the process to abort. TLS
destructors are executed after `main` returns on the main thread, and at
this point we've also deinitialized global `Lazy` values like those
which store the `Stderr` and `Stdout` internals. This means that despite
handling TLS not being accessible in `eprintln!`, we will fail due to
not being able to call `stderr()`. This means that we'll double-panic
quickly because panicking also attempt to write to stderr.
The fix here is to reimplement the global stderr handle to avoid the
need for destruction. This avoids the need for `Lazy` as well as the
hidden panic inside of the `stderr` function.
Overall this should improve the robustness of printing errors and/or
panics in weird situations, since the `stderr` accessor should be
infallible in more situations.
|
|
|
|
This commit fixes an issue where if `eprintln!` is used in a TLS
destructor it can accidentally cause the process to abort. TLS
destructors are executed after `main` returns on the main thread, and at
this point we've also deinitialized global `Lazy` values like those
which store the `Stderr` and `Stdout` internals. This means that despite
handling TLS not being accessible in `eprintln!`, we will fail due to
not being able to call `stderr()`. This means that we'll double-panic
quickly because panicking also attempt to write to stderr.
The fix here is to reimplement the global stderr handle to avoid the
need for destruction. This avoids the need for `Lazy` as well as the
hidden panic inside of the `stderr` function.
Overall this should improve the robustness of printing errors and/or
panics in weird situations, since the `stderr` accessor should be
infallible in more situations.
|
|
unix: Set a guard page at the end of signal stacks
This mitigates possible issues when signal stacks overflow, which could
manifest as segfaults or in unlucky circumstances possible clobbering of
other memory values as stack overflows tend to enable.
I went ahead and made a PR for this because it's a pretty small change, though if I should open an issue/RFC for this and discuss there first I'll happily do so. I've also added some example programs that demonstrate the uncomfortably clobber-happy behavior we currently have, and the segfaults that could/should result instead, [here](https://github.com/iximeow/jubilant-train).
|
|
Implement `Copy` for `IoSlice`
Resolves #69395
r? @sfackler
|
|
|
|
also unmap the whole thing when cleaning up, rather than leaving a spare
page floating around.
|
|
This mitigates possible issues when signal stacks overflow, which could
manifest as segfaults or in unlucky circumstances possible clobbering of
other memory values as stack overflows tend to enable.
|
|
Although `stack_overflow::init` runs very early in the process, even
before `main`, there may already be signal handlers installed for things
like the address sanitizer. In that case, just leave it alone, and don't
bother trying to allocate our own signal stacks either.
|
|
|
|
it. (clippy::redundant_static_lifetimes)
|
|
|
|
example:
let s: String = format!("hello").into();
|
|
|
|
macOS: avoid calling pthread_self() twice
|
|
|
|
It became unnecessary since a06baa56b95674fc626b3c3fd680d6a65357fe60 reformatted the file.
|
|
|
|
|
|
|
|
|
|
|
|
Standard library support for riscv64gc-unknown-linux-gnu
Add std support for RISC-V 64-bit GNU/Linux and update libc for RISC-V support.
r? @alexcrichton
|
|
Remove unused `#[link_name = "m"]` attributes
These were perhaps supposed to be `#[link(name = "m")]` but linking libm should be handled by the libc crate anyway.
They should have triggered a compile error: #47725
|
|
These were perhaps supposed to be `#[link(name = "m")]` but linking libm should be handled by the libc crate anyway.
|
|
|
|
|
|
`description` has been documented as soft-deprecated since 1.27.0 (17
months ago). There is no longer any reason to call it or implement it.
This commit:
- adds #[rustc_deprecated(since = "1.41.0")] to Error::description;
- moves description (and cause, which is also deprecated) below the
source and backtrace methods in the Error trait;
- reduces documentation of description and cause to take up much less
vertical real estate in rustdocs, while preserving the example that
shows how to render errors without needing to call description;
- removes the description function of all *currently unstable* Error
impls in the standard library;
- marks #[allow(deprecated)] the description function of all *stable*
Error impls in the standard library;
- replaces miscellaneous uses of description in example code and the
compiler.
|
|
|
|
|
|
|
|
Remove `SOCK_CLOEXEC` dummy variable on platforms that don't use it.
|
|
Fix up Command Debug output when arg0 is specified.
PR https://github.com/rust-lang/rust/pull/66512 added the ability to set argv[0] on
Command. As a side effect, it changed the Debug output to print both the program and
argv[0], which in practice results in stuttery output (`"echo" "echo" "foo"`).
This PR reverts the behaviour to the the old one, so that the command is only printed
once - unless arg0 has been set. In that case it emits `"[command]" "arg0" "arg1" ...`.
|
|
|
|
|
|
PR https://github.com/rust-lang/rust/pull/66512 added the ability to set argv[0] on
Command. As a side effect, it changed the Debug output to print both the program and
argv[0], which in practice results in stuttery output ("echo echo foo").
This PR reverts the behaviour to the the old one, so that the command is only printed
once - unless arg0 has been set. In that case it emits "[command] arg0 arg1 ...".
|
|
|
|
Replace .unwrap() with ? in std::os::unix::net
As people like to copy examples, this gives them good habits.
|
