CLOCKS_PER_SEC

[Dave Decot]

> What happened to the macro CLK_TCK in <time.h>?  Really old copies of
> the draft standard have it, but Dec 1988 has CLOCKS_PER_SEC instead.
> The POSIX documentation is full of stuff that depends on X3J11 defining
> this in <time.h>.  What should I do?

You should wait for the POSIX.1 supplement to fix it; CLK_TCK is obsolescent.

The problem was that ANSI retained the name clock(), but wanted to
change the units of the value that the function returned to be
implementation dependent.  So they had it return the value in CLK_TCKths
of a second.  All of this is very nice, because systems might want to
provide greater or lesser timing accuracy.

However, all known UNIX systems have clock() return the value in
microseconds, so CLK_TCK on UNIX systems would have to be 1000000
for backward compatibility.  However, CLK_TCK was used in all known
UNIX systems (and was required by POSIX.1) as the units returned by the
times() function, and the value of CLK_TCK for such systems was
traditionally 50 or 60.

Thus, systems wishing to conform to both POSIX.1 and ANSI C had a
problem; either break backward compatibility for times() or break it
for clock().

The correct move would have been for the ANSI committee to use some other
function name other than clock(), so that units of CLK_TCK could still be
returned by it, since such units are more logical.  A number of microseconds
overflows a 32 bit integer after only a few minutes, while a number of
actual system clock ticks would take much longer to overflow.

Unfortunately, the ANSI committee decided that renaming the clock()
function would be too major a change (even though incompatibly changing
the functionality wasn't), so they decided to change the name of the
units returned by clock() to CLOCKS_PER_SEC.  This puts systems conforming
to both POSIX.1 and ANSI C in the odd position of having two different
kinds of values stored in the same type, clock_t.

I still wish they would rename the function so that it would be useful
and so that clock_t would not have two entirely different meanings.

Dave Decot