quanta/clocks/monotonic/
unix.rs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#[derive(Clone, Copy, Debug, Default)]
pub struct Monotonic {
    _default: (),
}

impl Monotonic {
    #[allow(clippy::cast_sign_loss)]
    pub fn now(self) -> u64 {
        let mut ts = libc::timespec {
            tv_sec: 0,
            tv_nsec: 0,
        };
        unsafe {
            libc::clock_gettime(libc::CLOCK_MONOTONIC, &mut ts);
        }

        // LINT JUSTIFICATION:
        //
        // We really don't ever expect to actually _get_ negative values from `clock_gettime`, but
        // given the types, it's technically possible.  This is due to the fact that `tv_sec` is
        // supposed to be `time_t`, which Unix/POSIX-compliant systems implement as a signed number.
        // Accordingly, `tv_nsec` follows suit using a signed number.
        //
        // Given the adjustments made by NTP to clocks like CLOCK_MONOTONIC, and that
        // CLOCK_MONOTONIC can be anchored to an arbitrary point, and a whole skew of other
        // scenarios where it could be modified... it's technicaly possible to get back valid
        // negative values.  If we did math between `timespec` objects, the delta should be valid,
        // even with negative numbers.
        //
        // We're returning a u64 here, though, so it is what it is.  In practice, I've _never_ seen
        // negative values under normal operation.  If someone discovers a valid scenario where this
        // is violated and that we need to account for, I'll be colored impressed, but also, file an
        // issue and we'll do what we have to do to rework the code to try and support it better.
        //
        // Until then, though, we're just gonna ignore the lint.
        ts.tv_sec as u64 * 1_000_000_000 + ts.tv_nsec as u64
    }
}