refactor: fix definition of time_t and off_t in Newlib

[dybucc]

Description

This PR adresses bit-width representation issues under the newlib target environment concerned with both the time_t and off_t types.

In newlib, time_t is conditionally defined as being a c_longlong under the horizon and espidf target operating systems. Otherwise, it always defaults to using a 32-bit signed integer. off_t is always defined as a 64-bit signed integer except in espidf and in vita, where they are defined as c_long and c_int, respectively.

This is possibly incorrect. The newlib upstream repo maintained by Cygwin defines time_t conditionally as being either one of a c_long or a signed integer type with at least 64 bits precision. The definition will always default to the latter unless one issues --enable-newlib-long-time_t to the configure build script, or if the host system is known to have c_longs larger than 32 bits. In much the same vein, the espressif upstream repo for their fork of newlib uses the exact same definition, and so does the devkitARM shipped for development on horizon. Support for espidf with 32-bit time_t is likely provided for compatibility purposes following the analogous compatibility shims espressif has set in place in their upstream repos [1] [2].

Upstream also defines off_t in an ever so slightly different way to the declaration in the libc crate. The definition in the "official" repo maintained by the Cygwin developers will always provide a 64-bit value. The forks for vita, espressif's esp-32, devkitA64 (and by extension horizon in the Nintendo Switch but not in the Nintendo 3DS,) and RTEMS, don't define this type in the machine/_types.h header file. This header file is the one where the first definition for the type appears, and is the one that takes priority if it exists. A macro checks that in sys/_types.h, and will otherwise define the type in terms of a c_long. This only happens in the afore mentioned platforms, where the definition of off_t is removed from machine/_types.h. Currently, the exposed type is not completely wrong, but is quite defintely wrong in vita.

This patch changes the time_t definition to fit a 64-bit signed integer unless compiling for the afore mentioned environment (the one for time_t) with the existing cfg(espidf_time32) enabled. Note this option is "documented" as being meant for end users of the libc crate to enable, but no information on it is provided anywhere in all of the libc crate. It seems like the only users of that cfg are the projects in the esp-rs org. Some of the other targets using newlib have been verified to also follow this definition for time_t (sources below.) Among those checked are the ones for which we have custom modules at the end of the newlib/mod.rs module. Notably, no architecture-specific definitions were found for aarch64.

A simple test has been ran in all platforms except vita and aarch64 (which here means the Nintendo Switch with devkitPro's devkitA64) for both time_t and off_t. The former used a two-element array of time_t values and ensured that a write through an FFI routine (like time) only overwrote one of the values and not both. The latter required a bit more intricate testing, as no C standard library routine takes a mutable pointer to an off_t. All of the affected platforms required emulation and to some extent, supported embedding a virtual file system to the compiled binary. This was used to embed files with different sizes and use stream seeking operations with values for off_t both larger and smaller than 32 bits.

Testing was not possible in vita because the emulator did not support the type of homebrew package that the Rust toolchain for vita builds. In horizon for the Nintendo Switch under aarch64 with devkitA64, testing was neither possible for the same reason as in vita.

It would also be great to know whether the libc crate considers horizon to be the OS for both the Nintendo Switch and the Nintendo 3DS targets, or only for the Nintendo 3DS target. It just so happens that the newlib module has submodules for all three of them with a note that mentions testing only with devkitARM. Using cfg's for different architecures may not be the right choice, as there could be other systems whose ISA matched aarch64 with changes to their newlib fork that differ from those in devkitA64 (or any other devkitPro SDK, for that matter.)

Sources

• Cygwin's, espressif's and the Vita SDK's newlib forks showing conditional definition of the time_t type and the off_t type. Note Vita SDK's fork contains definitions relative to multiple target systems, but the one under include/sys has taken priority. The definition under include/vita/sys #includes the former to define its off_t type.

  https://github.com/cygwin/cygwin/blob/6926523688bab730ae1b56f24ad6fb203b7350af/newlib/libc/include/sys/_types.h#L185
  https://github.com/espressif/newlib-esp32/blob/esp-4.5.0/newlib/libc/include/sys/_types.h#L185
  https://github.com/search?q=repo%3Avitasdk%2Fnewlib+%2F%5Cb_time_t_%5Cb%2F&type=code
  https://github.com/cygwin/cygwin/blob/6926523688bab730ae1b56f24ad6fb203b7350af/newlib/libc/include/sys/_types.h#L100
  https://github.com/espressif/newlib-esp32/blob/67537d91e601c40e2b52b9b865518abb7eecc85b/newlib/libc/include/sys/_types.h#L100
  https://github.com/vitasdk/newlib/blob/fbb8375870d799758e0b4358d2f1708781aa26a6/newlib/libc/include/sys/_types.h#L100

  Sources on devkitARM could not be found online, but they can be found under the installed toolchain's directory in devkitARM/ by running ripgrep with the following command.

  rg -C 5 -S -uu -g "**/*.h" -e "\b_time_t_\b"

• Newlib sources documenting the configure build script non-default option for using a c_long for their time_t definition.

  https://github.com/cygwin/cygwin/blob/6926523688bab730ae1b56f24ad6fb203b7350af/newlib/README#L351

• Cygwin upstream codesearch showing the definition of _off_t, which defines __off_t, and eventually off_t. Note how this is defined in machine/_types.h (as an i64,) and later that is checked in sys/_types.h (falling back to a c_long.)

  https://github.com/search?q=repo%3Acygwin%2Fcygwin%20symbol%3A%2F%5Cb_*off_t%5Cb%2F&type=code

• espressif's esp-32 fork of newlib, vita's and RTEMS' showing how they don't have a definition in terms an i64 under machine/_types.h.

  https://github.com/search?q=repo%3Aespressif%2Fnewlib-esp32+path%3Anewlib%2Flibc%2Finclude+%2F%5Cb_*off_t%5Cb%2F&type=code
  https://github.com/search?q=repo%3Avitasdk%2Fnewlib+path%3Anewlib%2Flibc%2Finclude+%2F%5Cb_*off_t%5Cb%2F&type=code
  https://gitlab.rtems.org/search?search=path%3Anewlib%2Flibc%2Finclude+extension%3Ah+%22_*off_t%22&nav_source=navbar&project_id=416&group_id=1086&search_code=true&repository_ref=main

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 be failing for reasons unrelated to the changes introduced in the patch. A rerun should
do 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.