Yeah these calculations are a headache. I could probably write
now < start_time || now >= start_time + dwTimeout
to at least avoid a "hang" if GetTickCount counter overflows. This won't solve not waiting the required time if, say, start_time + dwTimeout overflows, and that can also be a problem (for example, I found this bug by bisecting a regression in an installer that happened because the function didn't properly wait). To be really purist, we would probably need a macro or a function with branching that correctly handles all possible overflow situations and tells if the required interval elapsed between "tick" values A and B. I wonder if a patch like that would be accepted, though, and also in what file this macro/function could be implemented?
This seems to be pretty widespread, too, one of CoWaitForMultipleHandles callers - RPC_GetLocalClassObject - now also has a similar timeout check.
Dan Kegel wrote:
if ((dwTimeout != INFINITE) && (start_time + dwTimeout >= now))
if ((dwTimeout != INFINITE) && (now >= start_time + dwTimeout))From time immemorial, it has been drummed into me
that one should always handle wraparound when checking timers. So something like DWORD delta = now - start_time; if (dwTimeout != INFINITE) && (delta < 0x80000000UL) && (delta > dwTimeout)) might be more correct... I used to always use a signed variable for this, but C compilers now treat overflow of signed variables as a conceptual error, so the subtraction has to be unsigned, There's probably a cleaner way to code this, but doing the subtraction to get the delta time, and then comparing against the maximum desired delta time, is the way to avoid trouble at rollover.
- Dan