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@xxxxxxxx> http://dotat.at/
SOUTH BISCAY: NORTHWESTERLY BECOMING VARIABLE 3 OR 4. MAINLY FAIR. GOOD.
To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-standards" in the body of the message
|
