Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!samsung!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: CLOCKS_PER_SEC
Message-ID: <11433@smoke.BRL.MIL>
Date: 27 Oct 89 19:59:18 GMT
References: <20538@princeton.Princeton.EDU> <11580019@hpisod2.HP.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 24

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?