Rollover/wraparound time of time.clock() under win32?

[Russell Warren]

Thanks!  That gets me exactly what I wanted.  I don't think I would
have been able to locate that code myself.

Based on this code and some quick math it confirms that not only will
the rollover be a looong way out, but that there will not be any loss
in precision until ~ 30 years down the road.  Checking my math:

  (float(10**16 + 1) - float(10**16)) == 0
  (float(10**15 + 1) - float(10**15)) == 1
  ie: our double precision float can resolve unity differences out to
      at least 10**15
  Assuming 1 us/count we have 10**15 us / (3.15E13 us/year) = 31.7 yrs

Past this we won't roll over since the long keeps counting for a long
time, but some precision will be lost.

For those interested, the relevant win32 time code is below.  Thanks
again!

time_clock(PyObject *self, PyObject *args)
{
	static LARGE_INTEGER ctrStart;
	static double divisor = 0.0;
	LARGE_INTEGER now;
	double diff;

	if (!PyArg_ParseTuple(args, ":clock"))
		return NULL;

	if (divisor == 0.0) {
		LARGE_INTEGER freq;
		QueryPerformanceCounter(&ctrStart);
		if (!QueryPerformanceFrequency(&freq) || freq.QuadPart == 0) {
			/* Unlikely to happen - this works on all intel
			   machines at least!  Revert to clock() */
			return PyFloat_FromDouble(clock());
		}
		divisor = (double)freq.QuadPart;
	}
	QueryPerformanceCounter(&now);
	diff = (double)(now.QuadPart - ctrStart.QuadPart);
	return PyFloat_FromDouble(diff / divisor);
}