Date: Tue, 28 May 2002 21:19:47 +0100 From: Tony Finch <dot@dotat.at> To: Bruce Evans <bde@zeta.org.au> Cc: Tony Finch <dot@dotat.at>, freebsd-standards@FreeBSD.ORG Subject: Re: clock(3) standardization Message-ID: <20020528211947.A20393@chiark.greenend.org.uk> In-Reply-To: <20020529051638.F22456-100000@gamplex.bde.org>; from bde@zeta.org.au on Wed, May 29, 2002 at 05:56:17AM %2B1000 References: <20020528191650.A8322@chiark.greenend.org.uk> <20020529051638.F22456-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 29, 2002 at 05:56:17AM +1000, Bruce Evans wrote: > On Tue, 28 May 2002, Tony Finch wrote: > > > I noticed that clock(3) currently violates a requirement of POSIX > > 2001 (that CLOCKS_PER_SEC is 1000000) and that the various archs > > are inconsistent and somtimes different from what is in clocks(7). > > That is only in a (broken) XSI extension. "Fixing" this would mainly > break binary compatibility since it would change from one historical > wrong value to another (128 -> 1000000). The first C standard got this > right by permitting it to be a runtime parameter. This value should > be <frequency of kernel timecounter> which may be a few billion on > current machines. This requires clock_t to be much larger than uint32_t > so that it can represent 24 hours in ticks. clock_t should probably be > double. But to do this would require changing the implementation to use something other than getrusage() to implement clock() and times(). Wouldn't it be better to add a non-standard interface for getting the higher resolution value, instead of being non-compliant? There's currently a discussion on comp.std.c about relaxing the C99 definition of CLOCKS_PER_SEC back to the C89 definition. > I actually prefer to let this rot and tell everyone to use clock_gettime(). We currently tell everyone to use getrusage(). Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ SOUTH BISCAY: NORTHWESTERLY BECOMING VARIABLE 3 OR 4. MAINLY FAIR. GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020528211947.A20393>