|
From: Keith M. <kei...@us...> - 2013-12-28 16:35:41
|
On 27/12/13 22:41, Keith Marshall wrote: > On 27/12/13 15:37, Pete McNeil wrote: >> I've been tracking down bugs here and there, but the latest is that >> diffetime() appears to be broken. > > I wonder: are you, perhaps running into a __time64_t vs. __time32_t issue. > >> Stepping through the app in gdb I watched to see reasonable values go >> into difftime(t1, t2), but it always seems to return t1. > > When you build your application with MinGW, unless you specifically > arrange to use an alternative non-distributable runtime DLL, difftime() > is furnished by MSVCRT.DLL. Depending on the version of MSVCRT.DLL > which is present on your host, the actual difftime() called may be a > __time32_t implementation, (expecting your t1 and t2 to be 32-bit), or > (in newer MSVCRT.DLL) it may be a __time64_t implementation, (expecting > 64-bit t1 and t2). Further follow up, with some experimentation, suggests that while this quote from http://msdn.microsoft.com/en-us/library/3wbd7281.aspx > difftime is an inline function that evaluates to either _difftime32 > or _difftime64 depending on whether _USE_32BIT_TIME_T is defined. may be true of the headers provided with recent versions of MSVC, it is not true of the difftime() exported by MSVCRT.DLL, (at least up to and including that on my Win7 VM); in this case, difftime() appears to be provided as a __time32_t implementation. Thus, the API declared for difftime(), in MinGW's wsl-4.0, is simply broken, since by default it assumes a __time64_t implementation, yet it directs the call to an actual implementation which is __time32_t. Bug report filed: https://sourceforge.net/p/mingw/bugs/2152/ -- Regards, Keith. |