get_time() does:
double get_time() {
return 1000*clock()/CLOCKS_PER_SEC;
}
Under Unix, clock returns clock_t. In Linux, this is a long. The above
line produces negative values for some calls to clock(). Since the
starting value is not specified, this can happen on any call. With the
multiplier of 1000, the range of potential negative values increases -
a value of 2147483 for example goes negative.
Under FreeBSD, clock_t is a unsigned long, which is not quite so bad.
This problem can happen for the time control routines as well. I'd
suggest changing the 1000 to 1000.0, so it might not overflow, and
casting the return from clock() to unsigned long.
A deeper problem is that clock() returns the time for the process
making the call. Under Unix and X, that does not include time spent in
the X server. So my laptop, without graphics acceleration, spent 11
minutes and 3 seconds doing a calibration and concluded I have a very
fast 3d display at 573 frames/second. The real answer is under 3
frames second, but it's all in the X rendering, so that time wasn't
counted. I would assume time controls will also be far to generous
when rendering boards under X.