Hi Jasen,

 > The best solution my be to build the processes to be
 > timed into the same
 > program as the call to clock. (or vice versa)

    I think I agree with that, but then it would be possible to use things
like difftime() and get a reliable result.

    The tiny program "timer.c" is intended to take an argument of
a program name, and give an approximation of the running time of the child
process in clocks-per-second. From that point of view it is a simple
utility which will give a result with any executable program.

    I never claimed any other accuracy for it. :-) It will certainly give a
numeric indication within 20 milliseconds, so that is good enough to tell
the difference between a program that takes 5 minutes, and one which takes
5 seconds to run.

    As a matter of interest I did recompile the squares program to use huge
numbers and not waste time in I/O. That reduced the execution time by a
factor of 1000, or was it 10,000, but it was still not possible to see any
difference between the version which allegedly re-evaluated sqrt(INT_MAX)
every iteration and the one which did it only once. To me that implies that
the optimizer did take care of it.

    Also my compilers had a problem using integers which exceed INT_MAX
because of limits.h. Had to switch to doubles.

Best Wishes,
Bill.

---