This was based on a misunderstanding.
On musl, 64-bit time_t on 32-bit architectures was introduced in version 1.2.0,
by introducing new symbols. The old symbols still exist, to allow programs compiled against older versions
to keep running on 1.2.0+, preserving ABI-compatibility. (see musl commit 38143339646a4ccce8afe298c34467767c899f51)
Programs compiled against 1.2.0+ will get the new symbols, and will therefore think time_t is 64-bit.
Unfortunately, rust's libc crate uses its own definition of these types, and does not check for musl version.
Currently, it includes the pre-1.2.0 32-bit type.
That means:
- If you run on a 32-bit system like i686
- ... and compile against a C-library other than libc
- ... and pass it a time_t-containing struct like timespec or stat
... you need to arrange for that library to be built against musl <1.2.0.
Or, as https://github.com/ericonr/rust-time64 says:
> Therefore, for "old" 32-bit targets (riscv32 is supposed to default to time64),
> any Rust code that interacts with C code built on musl after 1.2.0,
> using types based on time_t (arguably, the main ones are struct timespec and struct stat) in their interface,
> will be completely miscompiled.
However, while fish runs on i686 and compiles against pcre2, we do not pass pcre2 a time_t.
Our only uses of time_t are confined to interactions with libc, in which case with musl we would simply use the legacy ABI.
I have compiled an i686 fish against musl to confirm and can find no issue.
This reverts commit 55196ee2a0430d920ea7a2c89a6e322615f78334.
This reverts commit 4992f8896633fb8ca8d89e09f02330cd49395485.
This reverts commit 46c8ba2c9fec77195091ddcf7ee0bb3d9a6e5f54.
This reverts commit 3a9b4149da7d44b8648702f17d9e9eef651e56f9.
This reverts commit 5f9e9cbe741025231acfb24dc900433e1c6738ac.
This reverts commit 338579b78ca2ba0aab108304bc33a53fddeb11ba.
This reverts commit d19e5508d7b406da6813edb9d0a6909094d20e5a.
This reverts commit b64045dc189ec58b6bd3dea71e1441e00876904c.
Closes#10634
We only use this
1. if we have localeconv_l
2. to get the decimal point / thousands separator for numbers
So we can ignore all this and directly create a purely LC_NUMERIC locale.
This *was* more useful when we were in C++ and the printing functions
all relied on locale, but we only use this in printf and that only
extracts the number stuff.
* Fix build on NetBSD
Notably:
1. A typo in `f_flag` vs `f_flags` - this was probably never tested
2. Some pointless name differences - `st_mtimensec` vs
`st_mtime_nsec`
3. The big one: This said that LC_GLOBAL_LOCALE() was -1 "everywhere".
Well, not on NetBSD.
* ifdef for macos
This was previously limited to Linux predicated on the existence
of certain headers, but Rust just exposes those functions unconditionally. So
remove the check and just perform the mtime hack on Linux and Android.
