| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
This commit is an attempt to force `Instant::now` to be monotonic
through any means possible. We tried relying on OS/hardware/clock
implementations, but those seem buggy enough that we can't rely on them
in practice. This commit implements the same hammer Firefox recently
implemented (noted in #56612) which is to just keep whatever the lastest
`Instant::now()` return value was in memory, returning that instead of
the OS looks like it's moving backwards.
Closes #48514
Closes #49281
cc #51648
cc #56560
Closes #56612
Closes #56940
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Though CloudABI is strongly inspired by POSIX, its absence of features
that don't work well with capability-based sandboxing makes it different
enough that adding bits to sys/unix will make things a mess. This change
therefore adds CloudABI specific platform code under sys/cloudabi and
borrows parts from sys/unix that can be used without changes.
One of the goals of this implementation is to build as much as possible
directly on top of CloudABI's system call layer, as opposed to using the
C library. This is preferred, as the system call layer is supposed to be
stable, whereas the C library ABI technically is not. An advantage of
this approach is that it allows us to implement certain interfaces, such
as mutexes and condition variables more optimally. They can be lighter
than the ones provided by pthreads.
This change disables some modules that cannot realistically be
implemented right now. For example, libstd's pathname abstraction is not
designed with POSIX *at() (e.g., openat()) in mind. The *at() functions
are the only set of file system APIs available on CloudABI. There is no
global file system namespace, nor a process working directory.
Discussions on how to port these modules over are outside the scope of
this change.
Apart from this change, there are still some other minor fixups that
need to be made to platform independent code to make things build. These
will be sent out separately, so they can be reviewed more thoroughly.
|
