LIU Hao wrote: > 在 2026-2-18 03:09, Jacek Caban 写道: >> Sorry, I meant to question the rest of the series, which adds a number >> of wrappers. What is wrong with leaving 32-bit time in 64-bit builds >> unsupported on XP? Why do we need this? What makes it worth increasing >> binary size for everyone who uses 32-bit time? >> >> I think it's better to import these functions on x86 as well, as we >> currently do. However, if we really need to support those wrappers, then >> yes, we can assume they are available on arm64ec and import them >> directly instead. > > This makes sense. Not only is 64-bit `time_t` default on 64-bit targets, it > cannot be changed to 32-bit by defining `_USE_32BIT_TIME_T`. > > The question is probably, why would anyone call 32-bit time functions on > 64-bit systems? why they don't do casts instead?
Older versions of 64-bit msvcrt.dll (such as version 6.1) only export two symbols for each "time" function, e.g. `time` and `_time64`. The plain one is using 32-bit `time_t` (`__time32_t`). Later versions of 64-bit msvcrt.dll also export 32-bit versions, e.g. `_time32` which it is equivalent to plain `time`. Meanwhile, Microsoft documents all three versions; see documentation[1] for `time` as an example. Microsoft's header define `time` as an inline wrapper which calls either `_time32` or `_time64` depending on `_USE_32BIT_TIME_T`; mingw-w64's headers use inline assembly to rename the symbol. You are correct that `_USE_32BIT_TIME_T` is not allowed on 64-bit targets, but 32-bit versions of "time" functions are still available and can be used. If anyone compiles code which uses 32-bit versions such as `_time32`, such image will fail to load with old versions of msvcrt.dll because they do not export them. - Kirill Makurin [1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/time-time32-time64 _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
