Why is time_t defined as a 32-bit type on Windows?
Fri Aug 7 11:11:20 UTC 2020
On Friday, 7 August 2020 at 05:37:32 UTC, Andrej Mitrovic wrote:
> On Wednesday, 5 August 2020 at 16:13:19 UTC, Andrej Mitrovic
>> C:\dev> rdmd -m64 --eval="import core.stdc.time;
>> According to MSDN this should not be the case:
>>> time is a wrapper for _time64 and **time_t is, by default,
>>> equivalent to __time64_t**.
>> But in Druntime it's defined as a 32-bit type:
> I filed it as an issue to get more eyes / feedback:
As far as I gather, this was changed with MSVC 2005 , so
perhaps the relevent change wasn't applied to the druntime
windows bindings. Also keep in mind that we revamped a large
portion of the Windows bindins in 2015 , whose code was based
on MinGW IIRC.
> In versions of Visual C++ and Microsoft C/C++ before Visual
> Studio 2005, time_t was a long int (32 bits) and hence could
> not be used for dates past 3:14:07 January 19, 2038, UTC.
> time_t is now equivalent to __time64_t by default, but defining
> _USE_32BIT_TIME_T changes time_t to __time32_t and forces many
> time functions to call versions that take the 32-bit time_t.
> For more information, see Standard Types and comments in the
> documentation for the individual time functions.
(^ Source )
Edit: I see you're discussing core.stdc.time, which actually
wasn't part of the changes in . In any case, druntime should
offer both time_t, __time32_t, and __time64_t, and have time_t
time() default to 64-bit. I do wonder what exactly is exported
from UCRT as time(), as from the docs it looks it should be just
a macro, but if anyone had used time() one Windows (from D) and
didn't get linker errors or memory corruption, then I suppose
they're still defaulting it to 32-bit to avoid ABI breakages.
More information about the Digitalmars-d-learn