Different struct sizeof between linux and windows

Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri Jun 17 09:57:31 PDT 2016


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



More information about the Digitalmars-d-learn mailing list