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.
POSIX's clock_getres() is broken as designed too. It specifies returning
the precision in a timeval, by FreeBSD's potential resolution of (1
<frequency of kernel timecounter>) started overflowing a year or two
ago when TSC frequencies started exceeding 1 billion).
> This patch changes clock_t to a size that is consistent on all platforms
> and big enough to allow CLOCKS_PER_SEC to be increased to 1e6 without
> loss of range. This implies a binary compatibility breakage for programs
> that call clock() or times(), and therefore a __FreeBSD_version bump
> which I haven't included in this patch. I also haven't tested it yet :-)
I would prefer to break things only once in the transition to the correct
non-XSI-supporting implementation, something like this:
- clock_t of type double, long double or uint64_t or larger
- CLOCKS_PER_SECOND = ((clock_t)sysconf(_SC_CLK_TCK)) (this limits
it to LONG_MAX, but longs will soon always be >= 64 bits)
- sysconf(_SC_CLK_TCK) returns <frequency of kernel timecounter>
(scaled down a little if necessary)
I actually prefer to let this rot and tell everyone to use clock_gettime().
> This patch is rather repetitive. IWBNI the MI stuff in machine/ansi.h
> could be moved into an MI header, e.g. sys/ansi.h which might be included
> by machine/ansi.h or vice versa.
This is potentially very MD. E.g., uint64_t is a good type for clock_t
on 64-bit machines, but double is probably more efficient on 32-bit
ones. Machines with a clock frequency of 18.4 Hz need a double to
even represent the frequency. _BSD_CLOCKS_PER_SECOND_ was gratuitously
MD because most copies of it were cloned from a rotted value for CLK_TCK
in NetBSD starting with the alpha, despite the alpha not having any
binary compatibility baggage so it could have started with a reasonably
large value like 1e6 :-). Clocks.7 mentions too many clocks but doesn't
manage to mention any except old i386 ones.
Bruce
To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-standards" in the body of the message
|
