Render timing.c robust in the face of strangeness. The strangenesses

in question vary per OS: on Windows the problem is that WM_TIMER
sometimes goes off too early, so that GetTickCount() is right and
the callback time is wrong, whereas on Unix the problem is that my
GETTICKCOUNT implementation comes from the system clock which means
it can change suddenly and non-monotonically if the sysadmin is
messing about (meaning that the timing of callbacks from GTK or
select timeouts is _more_ likely to be right than GETTICKCOUNT).
This checkin provides band-aid workarounds for both problems, which
aren't pretty but ought to at least prevent catastrophic assertion
failure.

[originally from svn r5556]

unix/uxsftp.c

@@ -433,8 +433,27 @@ static int ssh_sftp_do_select(int include_stdin, int no_fds_ok)
 	    ret = select(maxfd, &rset, &wset, &xset, ptv);
 	    if (ret == 0)
 		now = next;
-	    else
-		now = GETTICKCOUNT();
+	    else {
+		long newnow = GETTICKCOUNT();
+		/*
+		 * Check to see whether the system clock has
+		 * changed massively during the select.
+		 */
+		if (newnow - now < 0 || newnow - now > next - now) {
+		    /*
+		     * If so, look at the elapsed time in the
+		     * select and use it to compute a new
+		     * tickcount_offset.
+		     */
+		    long othernow = now + tv.tv_sec * 1000 + tv.tv_usec / 1000;
+		    /* So we'd like GETTICKCOUNT to have returned othernow,
+		     * but instead it return newnow. Hence ... */
+		    tickcount_offset += othernow - newnow;
+		    now = othernow;
+		} else {
+		    now = newnow;
+		}
+	    }
 	} while (ret < 0 && errno != EINTR);
     } while (ret == 0);