This ML thread refers.
When _USE_32BIT_TIME_T is not defined, the default prototype in WSL time.h declares a prototype for difftime(), as a function accepting two __time64_t arguments, yet any call is simply directed to an external MSVCRT.DLL implementation which expects two __time32_t arguments.
MSDN tells us:
difftime is an inline function that evaluates to either _difftime32 or _difftime64 depending on whether _USE_32BIT_TIME_T is defined.
However, our header implementation fails to:
Provide the appropriate inline redirects.
Recognize that simple redirects to either _difftime64() or _difftime32(), as suggested by MSDN is not satisfactory, since neither of these functions is exported by MSVCRT.DLL on WinXP (or earlier). Thus, the redirect would need to:
Probe the DLL, to ensure that the redirection can be satisfied, before making the call.
Fall back to calling the strictly __time32_t implementation of difftime(), when the redirection cannot be completed.
On reflection, is it really necessary to even rely on
MSVCRT.DLLfor something as trivial asdifftime(), never mind probe it? I think not; the following is (mostly) independent ofMSVCRT.DLL:typedef __int32 __time32_t; typedef __int64 __time64_t; #if MSVCRT_VERSION < 700 || defined _USE_32BIT_TIME_T typedef __time32_t time_t; #else typedef __time64_t time_t; #endif static __inline__ double _difftime32( __time32_t __t1, __time32_t __t0 ) { return (double)((__time64_t)(__t1) - (__time64_t)(__t0)); } static __inline__ double _difftime64( __time64_t __t1, __time64_t __t0 ) { return (double)((long double)(__t1) - (long double)(__t0)); } #if MSVCRT_VERSION < 800 || defined _USE_32BIT_TIME_T static __inline__ double difftime( time_t __t1, time_t __t0 ) { return _difftime32( (__time32_t)(__t1), (__time32_t)(__t0) ); } #else static __inline__ double difftime( time_t __t1, time_t __t0 ) { return _difftime64( (__time64_t)(__t1), (__time64_t)(__t0) ); } #endifNote that, while the above provides an implementation of
difftime()which should work, regardless of theMSVCRT.DLLversion present on the run time host, it does highlight the anomaly which is responsible the the present broken implementation: the currenttime.hheader makestime_tequivalent to__time64_tfor allMSVCRT_VERSION, (and700is the default), unless_USE_32BIT_TIME_Tis defined, (which is just plain wrong for some -- indeed perhaps all -- of theMSVCRT.DLLversions still in use, without header file shenanigans to alter the underlying behaviour), but there is no workingdifftime()implementation specified in the (default) intervalMSVCRT_VERSION < 800.Last edit: Keith Marshall 2013-12-30