nfs@notecnirp.Princeton.EDU (Norbert Schlenker) (10/24/89)
I recently posted a note similar to this, but our external links were very flaky and I don't know whether it ever got out. I do know that no reply ever came back. 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? Norbert
decot@hpisod2.HP.COM (Dave Decot) (10/27/89)
> 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
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/28/89)
In article <20538@princeton.Princeton.EDU> nfs@notecnirp.UUCP (Norbert Schlenker) writes: >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? CLOCKS_PER_SEC was a last-minute correction to a longstanding error in the draft proposed C standard; somebody had pointed out to X3J11 that P1003 was using CLK_TCK for the conversion constant, and we picked it up for X3.159 as well, only realizing much later that we had made a horrible mistake, because the X3.159 and 1003.1 uses were NOT the same! My recommendation is to include the following in <time.h>: #define CLOCKS_PER_SEC 1000 /* all UNIX System V systems */ #ifdef _POSIX_SOURCE #define CLK_TCK 60 /* or whatever HZ is */ #endif CLK_TCK should really be defined in a POSIX-specific header, not in <time.h>, but due to IEEE Std 1003.1-1988 stating that it is defined in <time.h>, the above seems like the best solution. Note that you cannot conform to X3.159 if CLK_TCK is #defined by <time.h> without some form of extra-standard "feature test" like the above. Applications that expect to use the facilities that IEEE Std 1003.1 says are defined by the Standard C headers should always set _POSIX_SOURCE before including the standard headers, so the above kludge is fairly transparent.
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/28/89)
In article <11580019@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: >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. Not really, because the scheduler clock relevant for times() is usually coarser-grained than an available system timer as relevant for clock(). >Unfortunately, the ANSI committee decided that renaming the clock() >function would be too major a change (even though incompatibly changing >the functionality wasn't), ... clock() and times() both already existed and their units were already incompatible. X3J11 did not change the functionality of clock(); rather, we restored its original meaning (in accordance with early drafts and existing practice) to correct the inadvertent change in functionality we had introduced when we first borrowed CLK_TCK from the /usr/group library base document (or was it directly from 1003.1?). >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. Yes, for a while 1003.1 was using ttime_t. What happened to that? Did the X3J11 misuse of CLK_TCK mislead P1003 into changing to clock_t?