Remove redundant checked_cast, add utimes family

[carbotaniuman]

As the comment in one of the files says, I'm not sure what Rustix's story is wrt 64bit time on 32-bit systems.

This also adds some_or_ret_einval, which I'm down to bikeshed, but it should get rid of all the unwraps for parsing flags from bits.

[carbotaniuman]

Hmmm I thought x86 kernels didn't have 64 bit time support until 5.1, and we were still on 2.x something... Weird. It looks like we're 64-bit time always?

[sunfishcode]

Rustix uses 64-bit time types always, and uses the 64-bit APIs when the platform has them. It falls back to the 32-bit APIs when it needs to, though it converts everything to/from 64-bit types, and fails if the conversions ever fail. The idea is to be y2038-compatible when running on kernels that support the APIs to be y2038-compatible.

[sunfishcode]

That said, I believe mustang doesn't currently handle this correctly. Mustang should use libc's timespec_t and other types in its APIs, and convert to/from rustix's Timespec etc. as needed.

[carbotaniuman]

I am so confused as to how this breaks... It appears to be an ICE in some macro expansion code?

[carbotaniuman]

Ah, new Rust nightly ICE... Any reason with Rustix provides both futimes and utimensat? Just for ergonomic purposes, or is there some kernel difference?

[sunfishcode]

Passing a NULL pathname in utimensat is not portable outside of Linux, so having a separate futimens more closely reflects how the libc backend works. And ergonomics :-).

[sunfishcode]

It looks like the ICE might be due to rust-lang/rust#99261.

[sunfishcode]

main now has pinned a version of nightly; so if you rebase this on main it should be fixed.

[sunfishcode]

Thanks!