Open mezen opened 1 year ago
I'm hesitant to approve this change.
There are some places in Indy that don't use time_t
from the IdCTypes
unit. For instance, in the IdStackWindows
unit, IP_ADAPTER_INFO
is used, which has 2 time_t
members, and that time_t
is defined in Delphi's Winapi.IpTypes
unit as NativeInt
(and manually by Indy as NativeInt
when Winapi.IpTypes
is not available). Whereas in the IdSSLOpenSSLHeaders
unit, time_t
is used in X509_VERIFY_PARAM
, but that time_t
is hard-coded to LONG
, which is always 32bit in Windows.
Also, in C++Builder's time.h
C header, time_t
is defined as __int64
for Win64 and as long
otherwise, and long
is always 32bit on Windows. Which seems to contradict the Microsoft doc you quoted.
Perhaps these Delphi declarations initially didn't follow the Microsoft convention, or weren't updated correctly when the 64 bit era took off?
In fact: a coworker of me found this issue while he was trying to use the OpenSSL method ASN1_TIME_set
in a 32-bit application. With a 32-bit time_t
the function always failed, OpenSSL was expecting a 64-bit time_t
.
Another hint is the RTL function DateTimeToUnix
. Unix uses a time_t
for that value and the definition in Delphi is int64
.
And more interesting: MSDN says about IP_ADAPTER_INFO
in the remarks section:
When using Visual Studio 2005 and later, the
time_t
datatype defaults to an 8-byte datatype, not the 4-byte datatype used for theLeaseObtained
andLeaseExpires
members on a 32-bit platform. To properly use theIP_ADAPTER_INFO
structure on a 32-bit platform, define_USE_32BIT_TIME_T
(use-D _USE_32BIT_TIME_T
as an option, for example) when compiling the application to force thetime_t
datatype to a 4-byte datatype.
But if I try to use the API on my own, you are right, time_t
has to be bit-depended (32-bit on 32-bit programs, 64-bit on 64-bit programs).
And as MSDN always says about _USE_32BIT_TIME_T
: It depends on the compiler setting (if the macro is used or not).
It seams so it was used in the WinAPI.
But not every C Programm is the WinAPI.
While working on the new OpenSSL 3 IO Handler I already used my own type definition (mostly alias for the existing C Types like TIdOpenSSL_Int = TIdC_INT;
), so I could use a different definition there.
And more interesting: MSDN says about
IP_ADAPTER_INFO
in the remarks section:When using Visual Studio 2005 and later, the
time_t
datatype defaults to an 8-byte datatype, not the 4-byte datatype used for theLeaseObtained
andLeaseExpires
members on a 32-bit platform. To properly use theIP_ADAPTER_INFO
structure on a 32-bit platform, define_USE_32BIT_TIME_T
(use-D _USE_32BIT_TIME_T
as an option, for example) when compiling the application to force thetime_t
datatype to a 4-byte datatype.
Funny, they require those fields to be bit-dependant, so instead of just fixing the struct (ie, by using DWORD_PTR
instead), they require everyone to enable a setting that has global consequences. Good job, Microsoft!
Windows
time_t
differs from Unixtime_t
: the Windows version is not bit depending and always 64. In C and only on 32 bit you can use a macro to switch to 32-bittime_t
, but that is not the default and not recommended.Windows source: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/time-time32-time64
But on Unix and Linux systems
time_t
is bit depended.Unix Source: https://www.ibm.com/docs/en/ibm-mq/9.1?topic=platforms-standard-data-types-unix-linux-windows
I hope
{$IFDEF WINDOWS}
is the correct compiler directive for Indy.