Document that SystemTime does not count leap seconds
Fixes#77994
This may not be entirely uncontroversial. I know that `@Ekleog` is going to disagree. However, in support of this docs change:
This documents the current behaviour. The alternative would be to plan to *change* the behaviour.
There are many programs which need to get a POSIX time (a `time_t`). Right now, `duration_since(UNIX_EPOCH)` is the only facility in std that does that. So, that is what programs use. Changing the behaviour would break[1] all of those programs. We would need to define a new API that can be used to get a POSIX time, and get everyone to use it. This seems highly unpalatable.
And, even if we wanted to do that, time with leap seconds is a lot less easy to work with. We would need to arrange to have a leap seconds table available to `std` somehow, and make sure that it was kept up to date. Currently we don't offer to do that for timezone data, which has similar needs. There are other complications. So it seems it would be awkwarrd to *implement* a facility that provides time including leap seconds, and the resulting value would be hard for applications to work with.
Therefore, I think it's clear that we don't want to plan to ever change `SystemTime`. We should plan to keep it the way it is. Providing TAI (for example) should be left to external crates, or additional APIs we may add in the future.
For more discussion see #77994 and in particular `@fanf2's` https://github.com/rust-lang/rust/issues/77994#issuecomment-1409448174
[1] Of course, by "break" we really only mean *future* breakage in the case where there is, in fact, ever another leap second. There may well not be: they are in the process of being abolished (although this is of course being contested). But if we decide that `SystemTime::now().duraton_since(UNIX_EPOCH)` counts leap seconds, it would start to return `Durations`s that are 27s different to the current answers. That's clearly unacceptable. And we can hardly change `UNIX_EPOCH` by 27s.
wasi: round up the size for `aligned_alloc`
C11 `aligned_alloc` requires that the size be a multiple of the
alignment. This is enforced in the wasi-libc emmalloc implementation,
which always returns NULL if the size is not a multiple.
(The default `MALLOC_IMPL=dlmalloc` does not currently check this.)
Correct and expand documentation of `handle_alloc_error` and `set_alloc_error_hook`.
The primary goal of this change is to remove the false claim that `handle_alloc_error` always aborts; instead, code should be prepared for `handle_alloc_error` to possibly unwind, and be sound under that condition.
I saw other opportunities for improvement, so I have added all the following information:
* `handle_alloc_error` may panic instead of aborting. (Fixes#114898)
* What happens if a hook returns rather than diverging.
* A hook may panic. (This was already demonstrated in an example, but not stated in prose.)
* A hook must be sound to call — it cannot assume that it is only called by the runtime, since its function pointer can be retrieved by safe code.
I've checked these statements against the source code of `alloc` and `std`, but there may be nuances I haven't caught, so a careful review is welcome.
C11 `aligned_alloc` requires that the size be a multiple of the
alignment. This is enforced in the wasi-libc emmalloc implementation,
which always returns NULL if the size is not a multiple.
(The default `MALLOC_IMPL=dlmalloc` does not currently check this.)
Add a new helper to avoid calling io::Error::kind
On `cfg(unix)`, `Error::kind` emits an enormous jump table that LLVM seems unable to optimize out. I don't really understand why, but see for yourself: https://godbolt.org/z/17hY496KG
This change lets us check for `ErrorKind::Interrupted` without going through a big match. I've checked the codegen locally, and it has the desired effect on the codegen for `BufReader::read_exact`.
kmc-solid: Import `std::sync::PoisonError` in `std::sys::solid::os`
Follow-up to #114968. Fixes a missing import in [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets.
```
error[E0433]: failed to resolve: use of undeclared type `PoisonError`
C:\Users\xxxxx\.rustup\toolchains\nightly-2023-08-23-x86_64-pc-windows-gnu\lib\rustlib\src\rust\library\std\src\sys\solid\os.rs(85,36)
|
85 | ENV_LOCK.read().unwrap_or_else(PoisonError::into_inner)
| ^^^^^^^^^^^ use of undeclared type `PoisonError`
|
```
This is a pretty basic test but should spot any other platforms which
are `#[cfg(unix)]` but not Unix and where the wait status
representation is wrong. (And any actual Unix platforms where it's
not as expected, but I don't think they exist.)
I tried working with `UdpSocket` and ran into `EINVAL` errors with no
clear indication of what causes the error. Also, it was uncharacteristically
hard to figure this module out, compared to other Rust `std` modules.
1. `send` and `send_to` return a `usize`
This one is just clarity. Usually, returned `usize`s indicate that the
buffer might have only been sent partially. This is not the case with
UDP. Since that `usize` must always be `buffer.len()`, I have documented
that.
2. `bind` limits `connect` and `send_to`
When you bind to a limited address space like localhost, you can only
`connect` to addresses in that same address space. Error kind:
`AddrNotAvailable`.
3. `connect`ing to localhost locks you to localhost
On Linux, if you first `connect` to localhost, subsequent `connect`s to
non-localhost addresses fail. Error kind: `InvalidInput`.
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
Xous passes slice pointers around in order to manipulate memory.
This is feature-gated behind `slice_ptr_len`. Xous is currently
the only target to use this feature, so gate it behind an OS flag.
Signed-off-by: Sean Cross <sean@xobs.io>
Add an implementation of thread local storage. This uses a container
that is pointed to by the otherwise-unsed `$tp` register. This container
is allocated on-demand, so threads that use no TLS will not allocate
this extra memory.
Signed-off-by: Sean Cross <sean@xobs.io>
