From owner-freebsd-standards Tue May 28 13:19:53 2002 Delivered-To: freebsd-standards@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.135.138.206]) by hub.freebsd.org (Postfix) with ESMTP id B67A037B403 for ; Tue, 28 May 2002 13:19:50 -0700 (PDT) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 17CnRb-0007ct-00 (Debian); Tue, 28 May 2002 21:19:47 +0100 Date: Tue, 28 May 2002 21:19:47 +0100 From: Tony Finch To: Bruce Evans Cc: Tony Finch , freebsd-standards@FreeBSD.ORG Subject: Re: clock(3) standardization Message-ID: <20020528211947.A20393@chiark.greenend.org.uk> References: <20020528191650.A8322@chiark.greenend.org.uk> <20020529051638.F22456-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020529051638.F22456-100000@gamplex.bde.org>; from bde@zeta.org.au on Wed, May 29, 2002 at 05:56:17AM +1000 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 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 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 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