feat: deprecate windows time64_t

Functionality related to Windows `time64_t` has been deprecated in favor
of a single, 64-bit wide `time_t`. This has also required some work into
getting rid of the conditional compilation uses of `time_t` on GNU target
environments, and tweaking the `max_align_t` type.

The `FIXME` comment on the tier 1 platform support for Windows with GNU
has also been removed as no segfaults were observed.

Author: dybucc

libc-test/build.rs

@@ -753,7 +753,6 @@ fn test_cygwin(target: &str) {
 fn test_windows(target: &str) {
     assert!(target.contains("windows"));
     let gnu = target.contains("gnu");
-    let i686 = target.contains("i686");
 
     let mut cfg = ctest_cfg();
 
@@ -818,19 +817,9 @@ fn test_windows(target: &str) {
     cfg.skip_alias(move |alias| match alias.ident() {
         "SSIZE_T" if !gnu => true,
         "ssize_t" if !gnu => true,
-        // FIXME(windows): The size and alignment of this type are incorrect
-        "time_t" if gnu && i686 => true,
         _ => false,
     });
 
-    cfg.skip_struct(move |struct_| {
-        match struct_.ident() {
-            // FIXME(windows): The size and alignment of this struct are incorrect
-            "timespec" if gnu && i686 => true,
-            _ => false,
-        }
-    });
-
     cfg.skip_const(move |constant| {
         match constant.ident() {
             // FIXME(windows): API error:

libc-test/tests/windows_time.rs

@@ -0,0 +1,22 @@
+//! Ensures Windows `time`-related routines align with `libc`'s interface. By
+//! default, both MSVC and GNU (under `mingw`) expose 64-bit symbols. `libc`
+//! also does that, but there's been slight inconsistencies in the past.
+
+#![cfg(windows)]
+
+/// Ensures a 64-bit write is performed on values that should always be 64 bits.
+/// This may fail if
+/// (1) the routine links with its 32-bit variant. This only happens if
+///     `_USE_32BIT_TIME_T` is defined. In theory, this should not be
+///     possible when working with Rust's `libc`.
+/// (2) Or `time_t` is 32-bits, and a 64-bit write overwrites both array items.
+///     This should neither be possible unless the above macro is defined.
+///     Support for non-64-bit values in `libc` should thus be non-existent.
+#[test]
+fn test_64_bit_store() {
+    let mut time_values: [libc::time_t; 2] = [123, 456];
+    let ptr = time_values.as_mut_ptr();
+    unsafe { libc::time(ptr) };
+    assert!(time_values[0] != 123);
+    assert_eq!(time_values[1], 456);
+}

src/windows/mod.rs

@@ -18,13 +18,7 @@ pub type clock_t = i32;
 
 pub type errno_t = c_int;
 
-cfg_if! {
-    if #[cfg(all(target_arch = "x86", target_env = "gnu"))] {
-        pub type time_t = i32;
-    } else {
-        pub type time_t = i64;
-    }
-}
+pub type time_t = i64;
 
 pub type off_t = i32;
 pub type dev_t = u32;
@@ -34,6 +28,12 @@ extern_ty! {
     pub enum timezone {}
 }
 
+#[deprecated(
+    since = "1.0.0",
+    note = "This time-related value, among others, is part of the shift \
+            towards using a single, 64-bit-sized `time_t`. See #PENDING for \
+            discussion."
+)]
 pub type time64_t = i64;
 
 pub type SOCKET = crate::uintptr_t;