libc::clock_gettime clock types support is sub-par

[saethlin]

When run with MIRIFLAGS="-Zmiri-disable-isolation -Zmiri-check-number-validity", this program

fn main() {
    let mut tp = std::mem::MaybeUninit::<libc::timespec>::uninit();
    unsafe {
        libc::clock_gettime(libc::CLOCK_MONOTONIC_COARSE, tp.as_mut_ptr());
        tp.assume_init();
    };
}

Emits this:

error: Undefined Behavior: type validation failed at .value.tv_sec: encountered uninitialized bytes, but expected initialized plain (non-pointer) bytes
 --> src/main.rs:5:9
  |
5 |         tp.assume_init();
  |         ^^^^^^^^^^^^^^^^ type validation failed at .value.tv_sec: encountered uninitialized bytes, but expected initialized plain (non-pointer) bytes
  |
  = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
  = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
          
  = note: inside `main` at src/main.rs:5:9

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to previous error

That doesn't seem right to me.

[5225225]

Looking at the code, it looks like we don't support CLOCK_MONOTONIC_COARSE (we return -1).

So this is more "we should implement CLOCK_MONOTONIC_COARSE".

We could probably just treat it as an alias to CLOCK_MONOTONIC, I guess?

[saethlin]

This is more "the library I got this from should check the return value"

[RalfJung]

When clock_gettime returns an error, I would assume it is okay to not initialize the output param, so I don't think Miri is at fault? (Of course supporting more clocks would still be nice.)

[saethlin]

CLOCK_MONOTONIC_COARSE was added to Linux in version 2.6.32, that's the version supported in CentOS 6. May Ferris have mercy on anyone using Miri on a Linux older than CentOS 6.

I think we'd be justified to support all the clocks with the possible exception of CLOCK_BOOTIME, which was added in 2.6.39.

[RalfJung]

Oh we're certainly justified to support as much as we want. ;) We just usually barely support enough to cover what the standard lib needs.

One problem will just be implementing it. Though from the name of it we could treat it the same as CLOCK_MONOTONIC (as @5225225 said)?