Replace some `mem::forget`'s with `ManuallyDrop`
> but I would like to see a larger effort to replace all uses of `mem::forget`.
_Originally posted by `@saethlin` in https://github.com/rust-lang/rust/issues/127584#issuecomment-2226087767_
So,
r? `@saethlin`
Sorry, I have finished writing all of this before I got your response.
Fix build failure on vxworks #127084
PR to address issue #127084 .
1. Skip `reset_segpipe` for vxworks
2. Return unimplemented error for vxworks from settimes and lchown
3. Temporarily skip dirfd for vxworks
4. Add allow unused unsafe on read_at and write_at functions in unix/fs.rs
5. Using cfg disable ON_BROKEN_PIPE_FLAG_USED and on_broken_pipe_flag_used() for vxworks
6. Remove old crate::syscommon:🧵:min_stack() reference from process_vxworks.rs and update to set stack size of rtpthread
Thank you.
Fix return type of FileAttr methods on AIX target
At some point it seems `SystemTime::new` changed from returning `SystemTime` to `io::Result<SystemTime>`. This seems to have been addressed on other platforms, but was never changed for AIX.
This was caught by running
```
python3 x.py build --host x86_64-unknown-linux-gnu --target powerpc64-ibm-aix
```
Remove wrapper functions from c.rs
I'd like for the windows `c.rs` just to contain the basic platform definitions and not anything higher level unless absolutely necessary. So this removes some wrapper functions that weren't really necessary in any case. The functions are only used in a few places which themselves are relatively thin wrappers. The "interesting" bit is that we had an `AlertableIoFn` that abstracted over `ReadFileEx` and `WriteFileEx`. I've replaced this with a closure.
Also I removed an `#[allow(unsafe_op_in_unsafe_fn)]` while I was moving things around.
At some point it seems `SystemTime::new` changed from returning `SystemTime` to `io::Result<SystemTime>`. This seems to have been addressed on other platforms, but was never changed for AIX.
This was caught by running
```
python3 x.py build --host x86_64-unknown-linux-gnu --target powerpc64-ibm-aix
```
Clean up warnings + `unsafe_op_in_unsafe_fn` when building std for armv6k-nintendo-3ds
See #127747
ping `@AzureMarker` `@Meziu`
I could only find one instance needing an extra `unsafe` that was not also shared with many other `unix` targets (presumably these will get covered in larger sweeping changes, I didn't want to introduce churn that would potentially conflict with those). The one codepath I found is shared with `vita` however, so also pinging `@nikarh` `@pheki` `@zetanumbers` just to make sure they're aware of this change.
Also removed one unused import from `process_unsupported` which should simply fix the warning for any target that uses it.
Deal with invalid UTF-8 from `gai_strerror`
When the system is using a non-UTF-8 locale, the value will indeed not be UTF-8. That sucks for everyone involved, but is no reason for panic. We can "handle" this gracefully by just using from lossy, replacing the invalid UTF-8 with � and keeping the accidentally valid UTF-8. Good luck when debugging, but at least it's not a crash.
We already do this for `strerror_r`.
fixes#127563
When the system is using a non-UTF-8 locale, the value will indeed not
be UTF-8. That sucks for everyone involved, but is no reason for panic.
We can "handle" this gracefully by just using from lossy, replacing the
invalid UTF-8 with the ? and keeping the accidentally valid UTF-8.
Good luck when debugging, but at least it's not a crash.
We already do this for `strerror_r`.
Windows: move BSD socket shims to netc
On Windows we need to alter a few types so that they can be used in the cross-platform socket code. Currently these alterations are spread throughout the `c` module with some more in the `netc` module.
Let's gather all our BSD compatibility shims in the `netc` module so it's all in one place and easier to discover.
kmc-solid: `#![forbid(unsafe_op_in_unsafe_fn)]`
The path logic _should_ handle the forbiddance in the itron sources correctly, despite them being an "out-of-line" module.
unix: document unsafety for std `sig{action,altstack}`
I found many surprising elements here while trying to wrap a measly 5 functions with `unsafe`. I would rather not "just" mindlessly wrap this code with `unsafe { }`, so I decided to document it properly.
On Unix, this code covers the "create and setup signal handler" part of the stack overflow code, and serves as the primary safety boundary for the signal handler. It is rarely audited, very gnarly, and worth extra attention. It calls other unsafe functions defined in this module, but "can we correctly map the right memory, or find the right address ranges?" are separate questions, and get increasingly platform-specific. The question here is the more general "are we doing everything in the correct order, and setting up the handler in the correct way?"
As part of this audit, I noticed that we do some peculiar things that we should probably refrain from. However, I avoided making changes that I deemed might have a different final result in Rust programs. I did, however, reorder some events so that the signal handler is installed _after_ we install the alternate stack. We do not run much code between these events, but it is probably best if the timespan between the handler being available and the new stack being installed is 0 nanoseconds.
Add Process support for UEFI
UEFI does not have an actual process. However, it does provide methods to launch and execute another UEFI image. Having process support is important since it is possible to run rust test suit using `Command::output` and is the first step towards being able to run it for UEFI.
Here is an overview of how the support is implemented.
- We create a copy of the SystemTable. This is required since at least OVMF seems to crash if the original system table is modified.
- Stdout and Stderr pipe works by registering a new `simple_text_output` Protocol and pointing the child system table to use those.
- `Stdio::Inherit` just points the console to the current running image console which seems to work with even 3 levels of process.
- `spawn` is left unimplemented since it does not make sense for UEFI architecture. Additionally, since https://github.com/rust-lang/rust/pull/105458 was merged, the `spawn` and `output` implementations are completely independent.
- Update system table crc32
- Fix unsound use of Box
- Free exit data
- Code improvements
- Introduce OwnedTable
- Update r-efi to latest version
- Use extended_varargs_abi_support for
install_multiple_protocol_interfaces and
uninstall_multiple_protocol_interfaces
- Fix comments
- Stub out args implementation
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
This is technically "not necessary", as we will "just" segfault instead
if we e.g. arrive inside the handler fn with the null altstack. However,
it seems incorrect to go about this hoping that segfaulting is okay,
seeing as how our purpose here is to mitigate stack overflow problems.
Make sure NEED_ALTSTACK syncs with PAGE_SIZE when we do.
Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>
unix: break `stack_overflow::install_main_guard` into smaller fn
This was one big deeply-indented function for no reason. This made it hard to reason about the boundaries of its safety. Or just, y'know, read. Simplify it by splitting it into platform-specific functions, but which are still asked to keep compiling (a desirable property, since all of these OS use a similar API).
This is mostly a whitespace change, so I suggest reviewing it only after setting Files changed -> (the options gear) -> [x] Hide whitespace as that will make it easier to see how the code was actually broken up instead of raw line diffs.
Windows: Use futex implementation for `Once`
Keep the queue implementation for win7.
Inspired by PR #121956
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Prevent double reference in generic futex
In the Windows futex implementation we were a little lax at allowing references to references (i.e. `&&`) which can lead to deadlocks due to reading the wrong memory address. This uses a trait to tighten the constraints and ensure this doesn't happen.
r? libs
Make more Windows functions `#![deny(unsafe_op_in_unsafe_fn)]`
As part of #127747, I've evaluated some more Windows functions and added `unsafe` blocks where necessary. Some are just trivial wrappers that "inherit" the full unsafety of their function, but for others I've added some safety comments. A few functions weren't actually unsafe at all. I think they were just using `unsafe fn` to avoid an `unsafe {}` block.
I'm not touching `c.rs` yet because that is partially being addressed by another PR and also I have plans to further reduce the number of wrapper functions we have in there.
r? libs
This function is purely informative, answering where a stack starts.
This is a safe operation, even if an answer requires unsafe code,
and even if the result is some unsafe code decides to trust the answer.
It also doesn't need to fetch the PAGE_SIZE when its caller just did so!
Let's complicate its signature and in doing so simplify its operation.
This allows sprinkling around #[forbid(unsafe_op_in_unsafe_fn)]
