feat: add support for 32 bit time_t in Windows

[dybucc]

Description

This PR adds support symmetric to that offered in some Unix platforms for using 32-bit time_t in Windows. This PR also removes some of the skip() functions used with ctest in Windows, as it renames some symbols to properly reflect whether they are 32-bit or 64-bit compliant, and adds deprecation notices to functions that are not supported by Microsoft anymore (as per their security guidelines.)

There's a few functions with secure variants (suffixed with _s) that are altogether missing and yet do appear in the Windows CRT docs, but that's work for another PR.

In the CI scripts, there seemed to be a slight inconsistency between what the environment variable ARCH, and the environment variable ARCH_BITS were meant to be checked for, so that also got tweaked.

An issue for the deprecation notices hasn't yet been opened, but if the PR seems viable, it can be readily opened before merging.

Sources

• Example of function documented in the Windows CRT with secure variants, and the corresponding functionality when _USE_32BIT_TIME_T is defined.
  https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/ctime-s-ctime32-s-ctime64-s-wctime-s-wctime32-s-wctime64-s?view=msvc-170
• Microsoft security guidelines, mentioning deprecation of functions for which there's secure, _s-suffixed variants.
  https://learn.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt?view=msvc-170

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

@rustbot label +stable-nominated

[rustbot]

Some changes occurred in a solarish module

cc @jclulow, @pfmooney

Some changes occurred in an OpenBSD module

cc @semarie

Some changes occurred in a NetBSD-like module

cc @semarie

Some changes occurred in an Android module

cc @maurer

[tgross35]

What is the point of this? Per @ChrisDenton, _USE_32BIT_TIME_T has been deprecated a long time ago #gsoc > Idea: modernize the libc crate @ 💬.

All other changes resulted from running ./ci/style.py, so they're not really part of the PR.

The vast majority of this PR is reformatting, I suspect your local rustfmt isn't picking up .rustfmt.toml for some reason. If there really was that amount of reformatting to do, it should be a separate PR anyway rather than mixed in with other API changes.

[dybucc]

What is the point of this? Per @ChrisDenton, _USE_32BIT_TIME_T has been deprecated a long time ago #gsoc > Idea: modernize the libc crate @ 💬.

All other changes resulted from running ./ci/style.py, so they're not really part of the PR.

The vast majority of this PR is reformatting, I suspect your local rustfmt isn't picking up .rustfmt.toml for some reason. If there really was that amount of reformatting to do, it should be a separate PR anyway rather than mixed in with other API changes.

Just ammended the commit without the formatting changes. Adding support for _USE_32BIT_TIME_T was to be a tad bit more compliant with the Microsoft CRT docs, and how they seem to have routines specific to both time64_t, time32_t, and time_t, the latter depending on whether the above feature test macro is defined.

The reason why the PR was opened was because some uses of the ctest's skip_* methods in test_windows under libc-test got removed without affecting test success. This may or may not have been due to the changes in this PR.

Should the PR be altogether closed, or should the changes to add support for _USE_32BIT_TIME_T be the only ones removed?

[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]

Are you referring to this?

libc/libc-test/build.rs

Lines 784 to 785 in 82b7480

	// FIXME(windows): these don't exist:
	"time64_t" => "__time64_t".to_string().into(),

If so, the fix here is to deprecate the alias on Windows so we can remove it in 1.0. We don't have any reason to try to support the legacy behavior.

[dybucc]

No, the PR only changes types that relied on time_t, or time_t itself, as those trusted the feature test macro to be defined for correct size and alignment (e.g. timespec.) Types like time64_t, which are renamed anyway into the documented Microsoft CRT types aren't touched, but could be readily deprecated.

Still, what's the point of deprecating the time64_t alias for __time64_t if that's, in principle, not using the legacy 32-bit time_t?

EDIT: Sorry, took a while to realize you mean to deprecate time64_t in favor of a single, 64-bit, time_t. It can be done, but not just yet (working on a different PR.)

[tgross35]

The bigger picture is that time64_t types (along with off64_t, functions like open64, etc) are a bit of a bandaid that doesn't need to exist if you have a need to mix different sizes of time_t. In libc 1.0 we're going to be deprecating or dropping support for 32-bit time_t wherever possible, so there isn't any purpose to having the compatibility shims around.