refactor: change definition of time_t in TEEOS

[dybucc]

Description

This PR aims to both discuss and (possibly) change the bit-width of the time_t type in TEEOS. At present, we expose a single time_t type whose bit-width relies on semantics specific to each target system, as c_long is likely to be 64-bit wide under platforms following LP64 and 32-bit wide under platforms following LLP64, but there's a few things that lead me to believe this may cause conflicts in TEEOS.

The first issue I would like to address is that if we're exposing the time_t definition in the OhOS SDK that TEEOS uses, our current definition is not completely correct. SDKs for all three of Darwin, Linux and Windows use the same definition as musl; Namely, typedef _Int64 time_t. In libc, though, we expose it as a c_long.

Just to be sure, though, I then looked at the TEEOS upstream kernel repo, and they define time_t in terms of either one of a 32-bit unsigned integer or a 64-bit unsigned integer, depending on the machine's word size. That implies this target OS likely supports running on both such types of machines, which means that our current definition is sort of OK on the bitwidth side but not on the signed integer side.

The proposed change in this PR switches the type to be an explicit 64-bit signed integer, though this has not taken into account the definition in the TEEOS kernel. That's why I would like to spark some discussion on this, or otherwise call it a day and learn something new.

Sources

• A regex search through the downloadable OhOS SDK shows that all type definitions accross architectures follow musl's. For reference, I ran ripgrep across the SDKs for Darwin, Linux and Windows with the following command:

  rg -g "**/alltypes.h" -e "\btime_t\b"

  I also ran it by more generally scoping the search to header files, but relevant results were the same.

• TEEOS kernel sources defining time_t as an unsigned integer.

  https://github.com/openharmony/tee_tee_os_kernel/blob/fc85968fa01f6503997a50f09f1fc11e832860d9/kernel/include/common/types.h#L50

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget); especially relevant for platforms that may not be checked in CI

[dybucc]

CI seems to have failed for reasons unrelated to the changes introduced in this PR. Rerunning it
will likely solve it.

[dybucc]

CI actually passes. There seems to be an issue with a glob import that is not used, but this has not
been changed in the patch (it's not even part of it, for that matter.) For some reason, rebasing
onto main with dependabot updates has ended up with a warning across all of my open PRs due to
that one (now apparently unused) import.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[tgross35]

At least for OhOS it was the case that support was added after musl's switch to 64-bit only, meaning the platform never had a chance of supporting 32-bit (a couple of these platforms are in this boat https://github.com/rust-lang/libc/blame/e34c8b6da178f87bfbb4613fa9b7a8318548eff3/build.rs#L118-L119). So I'd expect the same thing here, either i64 or c_longlong is fine.

View changes since this review

[dybucc]

An i64 it is then (that's what submitted in this patch.)