On Friday, June 17, 2016 13:21:04 Vladimir Panteleev via Digitalmars-d-learn wrote: > On Friday, 17 June 2016 at 13:11:35 UTC, Kagamin wrote: > > time_t is 64-bit on windows: > > https://msdn.microsoft.com/en-us/library/1f4c8f33.aspx > > Windows does not have the concept of "time_t". The C runtime in > use does. > > We use the DigitalMars C runtime for the 32-bit model, which is > the default one. The Microsoft one is used for 64-bit and 32-bit > COFF. I'm not sure how the MS C library deals with time_t, > however the time() function (as exported from the library file / > DLL) is the 32-bit version. If I were to guess, the C headers > define a macro which redirects time() calls to the 64-bit version > when appropriate. The D bindings don't copy that behavior.
The VS C runtime uses a macro to indicate whether time_t should be treated as 32-bit or 64-bit on 32-bit systems. I thought that the default was 32-bit, but it looks like it's actually 64-bit, with the macro being _USE_32BIT_TIME_T. https://msdn.microsoft.com/en-us/library/1f4c8f33(v=vs.140).aspx I guess that that the correct way to handle that would be to make it so that druntime defines it as 64-bit by default and then has a version identifier to change the behavior, but I don't know how that sort of thing has been handled with the Win32 stuff in general. In the case of the stupid unicode-related macros, IIRC, the solution is to just force you to use either the A or W functions explicitly (preferably the W functions) rather than making either of them the default or using a version identifier. That approach really isn't an option here though, since the names don't changee but rather the types. - Jonathan M Davis