On Friday, 17 June 2016 at 16:25:15 UTC, Vladimir Panteleev wrote:
If I were to import the time() function from MSVCR*.dll, what
size its return value would be?
MSVC runtime dll doesn't export `time` function, it exports
_time32 and _time64. `time` is a wrapper in the import library,
its
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
On Friday, 17 June 2016 at 16:16:48 UTC, Kagamin wrote:
On Friday, 17 June 2016 at 13:21:04 UTC, Vladimir Panteleev
wrote:
Windows does not have the concept of "time_t". The C runtime
in use does.
The D bindings don't copy that behavior.
D defining C runtime type different from C runtime
On Friday, 17 June 2016 at 13:21:04 UTC, Vladimir Panteleev wrote:
Windows does not have the concept of "time_t". The C runtime in
use does.
The D bindings don't copy that behavior.
D defining C runtime type different from C runtime causes this
error.
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
time_t is 64-bit on windows:
https://msdn.microsoft.com/en-us/library/1f4c8f33.aspx
On Friday, 17 June 2016 at 07:11:28 UTC, Vladimir Panteleev wrote:
On Friday, 17 June 2016 at 06:54:36 UTC, Andre Pany wrote:
Is this behavior correct?
Yes. time_t is defined as C long on Linux (meaning it'll be
64-bit in 64-bit programs), however it's always 32-bit on the
Windows C
On Friday, 17 June 2016 at 06:54:36 UTC, Andre Pany wrote:
Is this behavior correct?
Yes. time_t is defined as C long on Linux (meaning it'll be
64-bit in 64-bit programs), however it's always 32-bit on the
Windows C runtimes we use.
