Make std::os::unix/linux::fs::MetadataExt::a/m/ctime* documentation clearer
I was confused by this API so I clarified what they are doing.
I was wondering if I should try to unify more documentation and examples between `unix` and `linux` (e.g. “of the file” is used in `unix` to refer to the file these metadata is for, “of this file” in `linux`, “of the underlying file” in `std::fs::File`).
Implement checked_add_duration for SystemTime
[Original discussion on the rust user forum](https://users.rust-lang.org/t/std-systemtime-misses-a-checked-add-function/21785)
Since `SystemTime` is opaque there is no way to check if the result of an addition will be in bounds. That makes the `Add<Duration>` trait completely unusable with untrusted data. This is a big problem because adding a `Duration` to `UNIX_EPOCH` is the standard way of constructing a `SystemTime` from a unix timestamp.
This PR implements `checked_add_duration(&self, &Duration) -> Option<SystemTime>` for `std::time::SystemTime` and as a prerequisite also for all platform specific time structs. This also led to the refactoring of many `add_duration(&self, &Duration) -> SystemTime` functions to avoid redundancy (they now unwrap the result of `checked_add_duration`).
Some basic unit tests for the newly introduced function were added too.
I wasn't sure which stabilization attribute to add to the newly introduced function, so I just chose `#[stable(feature = "time_checked_add", since = "1.32.0")]` for now to make it compile. Please let me know how I should change it or if I violated any other conventions.
P.S.: I could only test on Linux so far, so I don't necessarily expect it to compile for all platforms.
Since SystemTime is opaque there is no way to check if the result
of an addition will be in bounds. That makes the Add<Duration>
trait completely unusable with untrusted data. This is a big problem
because adding a Duration to UNIX_EPOCH is the standard way of
constructing a SystemTime from a unix timestamp.
This commit implements checked_add_duration(&self, &Duration) -> Option<SystemTime>
for std::time::SystemTime and as a prerequisite also for all platform
specific time structs. This also led to the refactoring of many
add_duration(&self, &Duration) -> SystemTime functions to avoid
redundancy (they now unwrap the result of checked_add_duration).
Some basic unit tests for the newly introduced function were added
too.
This commit, after reverting #55359, applies a different fix for #46775
while also fixing #55775. The basic idea was to go back to pre-#55359
libstd, and then fix#46775 in a way that doesn't expose #55775.
The issue described in #46775 boils down to two problems:
* First, the global environment is reset during `exec` but, but if the
`exec` call fails then the global environment was a dangling pointer
into free'd memory as the block of memory was deallocated when
`Command` is dropped. This is fixed in this commit by installing a
`Drop` stack object which ensures that the `environ` pointer is
preserved on a failing `exec`.
* Second, the global environment was accessed in an unsynchronized
fashion during `exec`. This was fixed by ensuring that the
Rust-specific environment lock is acquired for these system-level
operations.
Thanks to Alex Gaynor for pioneering the solution here!
Closes#55775
Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>
This commit deletes the `alloc_system` crate from the standard
distribution. This unstable crate is no longer needed in the modern
stable global allocator world, but rather its functionality is folded
directly into the standard library. The standard library was already the
only stable location to access this crate, and as a result this should
not affect any stable code.
Instead, pass the environment to execvpe, so the kernel can apply it directly to the new process. This avoids a use-after-free in the case where exec'ing the new process fails for any reason, as well as a race condition if there are other threads alive during the exec.
Reduce number of syscalls in `rand`
This skips the initial zero-length `getrandom` call and
directly hands the user buffer to the operating system, saving one
`getrandom` syscall.
set cfg(rustdoc) when rustdoc is running on a crate
When using `#[doc(cfg)]` to document platform-specific items, it's a little cumbersome to get all the platforms' items to appear all at once. For example, the standard library adds `--cfg dox` to rustdoc's command line whenever it builds docs, and the documentation for `#![feature(doc_cfg)]` suggests using a Cargo feature to approximate the same thing. This is a little awkward, because you always need to remember to set `--features dox` whenever you build documentation.
This PR proposes making rustdoc set `#[cfg(rustdoc)]` whenever it runs on a crate, to provide an officially-sanctioned version of this that is set automatically. This way, there's a standardized way to declare that a certain version of an item is specifically when building docs.
To try to prevent the spread of this feature from happening too quickly, this PR also restricts the use of this flag to whenever `#![feature(doc_cfg)]` is active. I'm sure there are other uses for this, but right now i'm tying it to this feature. (If it makes more sense to give this its own feature, i can easily do that.)
In case that it is statically known that the OS doesn't support
`getrandom` (non-Linux) or becomes clear at runtime that `getrandom`
isn't available (`ENOSYS`), the opened fd ("/dev/urandom") isn't closed
after the function, so that future calls can reuse it. This saves
repeated `open`/`close` system calls at the cost of one permanently open
fd.
Additionally, this skips the initial zero-length `getrandom` call and
directly hands the user buffer to the operating system, saving one
`getrandom` syscall.
clarify partially initialized Mutex issues
Using a `sys_common::mutex::Mutex` without calling `init` is dangerous, and yet there are some places that do this. I tried to find all of them and add an appropriate comment about reentrancy.
I found two places where (I think) reentrancy can actually occur, and was not able to come up with an argument for why this is okay. Someone who knows `io::lazy` and/or `sys_common::at_exit_imp` should have a careful look at this.
As a start, the port uses the simplest possible configuration (no jemalloc, abort on panic)
and makes use of existing Unix-specific code wherever possible.
It adds targets for x86_64 (current main HermitCore platform) and aarch64 (HermitCore platform
under development).
Together with the patches to "liblibc" and "llvm", this enables HermitCore applications to be
written in Rust.
Unix sockets on redox
This is done using the ipcd daemon. It's not exactly like unix sockets because there is not actually a physical file for the path, but it's close enough for a basic implementation :)
This allows mio-uds and tokio-uds to work with a few modifications as well, which is exciting!
Add read_exact_at and write_all_at methods to FileExt on unix
This PR adds `FileExt::read_exact_at()` and `FileExt::write_all_at()`, which are to `read_at()` and `write_at()` as `read_exact()` and `write_all()` are to `read()` and `write()`. This allows the user to not have to deal with `ErrorKind::Interrupted` and calling the functions in a loop.
I was unsure as to how to mark these new methods so I marked them `unstable`, please let me know if I should have done it differently.
I asked in Discord and was told that as this change is small it does not require an RFC.
