Improper use of GetTickCount

[mkujawa]

e9ababd#diff-0a54b726bba1300aed45ad5693c349d1 has introduced a warning regression by switching from a compile-time check to a run-time check, but highlights a real bug.

I did this

Compiled for windows with msvc /analyze and many warnings enabled

I expected the following

Clean compilation. But instead,

  curl\lib\timeval.c(55): error C2220: warning treated as error - no 'object' file generated
  curl\lib\timeval.c(50) : warning C28159: Consider using 'GetTickCount64' instead of 'GetTickCount'. Reason: GetTickCount overflows roughly every 49 days.  Code that does not take that into account can loop indefinitely.  GetTickCount64 operates on 64 bit values and does not have that problem

And that warning is highlighting a real bug with this code. GetTickCount() should not be used as a monotonically increasing time source. Instead, you should store your own count and increment it by the change in GetTickCount().

Pseudocode:

  static DWORDLONG ticks = {};
  static DWORD lastMilliseconds = 0;
  DWORD curMilliseconds = GetTickCount();
  if ( lastMilliseconds )
  {
    ticks += (curMilliseconds - lastMilliseconds);
  }
  lastMilliseconds = curMilliseconds;
  now.tv_sec = (time_t)(ticks / 1000);
  now.tv_usec = (unsigned int)(ticks % 1000);

This will have no overflow issues so long as it's called more frequently than once every 2^31-1 milliseconds. My pseudocode does have issues with multiple threads, though.

curl/libcurl version

251cabf

operating system

Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64

[bagder]

Won't that cause multi-threading issues? (which I then noticed you also mentioned)

[bagder]

A proper fix would rather instead use GetTickCount64() if a new enough Windows version is used.

[mkujawa]

While GetTickCount64 is an easy and proper fix for newer windows, it would still leave older windows vulnerable to overflow. If there continues to be a GetTickCount fallback, it should be correct.

[bagder]

I won't disagree with that. But I can note that not a single person has reported an actual problem with this in the past so I don't consider it a very big problem...

[jay]

We recently accepted an enhancement on this function to use QueryPerformance instead of GetTickCount64 for Vista+ for higher resolution. The issue reported here AFAICT affects <=XP which has been a known issue (or, at least, I knew about it...).

[bagder]

Ah right then GetTickCount64() isn't going to be useful since when that is available, a better solution is already used.

The amount of users on <= XP that cares about this (minor) issue I would suspect is rather small. I'll nominate it for KNOWN_BUGS and be done with it.

[mkujawa]

That still leaves the compiler warning

[bagder]

We will happily appreciate and welcome patches fixing that.

[jay]

The warning is techinically correct. The analyzer is not smart enough to understand that the function is only called on versions of Windows that don't have GetTickCount64. You may be able to __pragma push and pop disabling the warning for just that area.

[MarcelRaad]

Or maybe the else branch using GetTickCount could just be disabled at compile time when targeting >= Vista? The VS code analysis that complains about this only runs with the Vista+ toolset anyway, and it's just dead code in that case.

[mkujawa]

Or maybe the else branch using GetTickCount could just be disabled at compile time when targeting >= Vista? The VS code analysis that complains about this only runs with the Vista+ toolset anyway, and it's just dead code in that case.

That was the old approach. The current code supports compiling a single binary that will use QueryPerformanceCounter on Vista and GetTickCount on <= XP. The windows api level define could be checked, but that still wouldn't fix the case of compiling with the new tools but targeting WINVER 0x0500