Re: [Mingw-users] difftime() broken?

[Keith M. <kei...@us...>]

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).

> For example:
> 
> int snfLOGmgr::SecsSinceStartup() {
>      return (int) difftime(Timestamp(), StartupTime);
> }
> 
> If StartupTime is 1388157426, and Timestamp() returns 1388157546, 
> difftime should return 120.
> 
> Instead it returns 1388157546!!

I'd expect that, if you passed __time64_t t1 and t2 to a __time32_t
difftime() implementation.  With MinGW runtimes prior to v4.0, all time
functions were assumed to be __time32_t implementations; v4.0 and later
now adopt the Microsoft convention of assuming __time64_t, unless you
define _USE_32BIT_TIME_T.

In my opinion, this _USE_32BIT_TIME_T kludge is utterly broken by
design; much better, I think, to explicitly call the explicitly typed
functions, (_difftime32() or _difftime64() in the present case), rather
than the ambiguous kludge dependent implicit function, (difftime()
here).  To make this completely robust, and to maintain compatibility
with older hosts, it is also necessary to probe the actual version of
MSVCRT.DLL on the run time host, to ensure that the explicit function is
actually available, before calling it, otherwise falling back to the
older implicit name, assuming it then expects __time32_t semantics[*].

[*] Yes, you might reasonably expect that MinGW's implementation would
handle this in this robust fashion; unfortunately, Earnie has declined
to implement it so, preferring to simply mimic the (broken) Microsoft
inspired kludgy behaviour.

-- 
Regards,
Keith.