From owner-freebsd-standards Tue May 28 12:53:39 2002 Delivered-To: freebsd-standards@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 40E0537B417 for ; Tue, 28 May 2002 12:53:08 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA13792; Wed, 29 May 2002 05:52:59 +1000 Date: Wed, 29 May 2002 05:56:17 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Tony Finch Cc: freebsd-standards@FreeBSD.ORG Subject: Re: clock(3) standardization In-Reply-To: <20020528191650.A8322@chiark.greenend.org.uk> Message-ID: <20020529051638.F22456-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 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 ) 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 (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@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message