From nobody@FreeBSD.org  Mon Sep  3 15:29:40 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id AB49737B406
	for <freebsd-gnats-submit@FreeBSD.org>; Mon,  3 Sep 2001 15:29:39 -0700 (PDT)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.4/8.11.4) id f83MTd301051;
	Mon, 3 Sep 2001 15:29:39 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200109032229.f83MTd301051@freefall.freebsd.org>
Date: Mon, 3 Sep 2001 15:29:39 -0700 (PDT)
From: Bernd Luevelsmeyer <bdluevel@heitec.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: CLOCKS_PER_SEC non-standard
X-Send-Pr-Version: www-1.0

>Number:         30297
>Category:       misc
>Synopsis:       CLOCKS_PER_SEC non-standard
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    dwmalone
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 03 15:30:01 PDT 2001
>Closed-Date:    Sat Feb 16 06:08:53 PST 2002
>Last-Modified:  Sat Feb 16 06:09:26 PST 2002
>Originator:     Bernd Luevelsmeyer
>Release:        4.4-RC
>Organization:
>Environment:
FreeBSD 4.4-RC i386
>Description:
CLOCKS_PER_SEC in the #include-file <time.h> is 128.
"The Single UNIX Specification" at
http://www.UNIX-systems.org/online.html however says
"CLOCKS_PER_SEC is defined to be one million in <time.h>", and
the Red Hat Linux 7.2 manpage says "POSIX requires
that CLOCKS_PER_SEC equals 1000000 independent of the actual
resolution."
>How-To-Repeat:

>Fix:
If POSIX indeed requires CLOCKS_PER_SEC to be one million then
it should be changed to that value, in order to enhance
Standard conformance.
>Release-Note:
>Audit-Trail:

From: David Malone <dwmalone@maths.tcd.ie>
To: Bernd Luevelsmeyer <bdluevel@heitec.net>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/30297: CLOCKS_PER_SEC non-standard
Date: Tue, 4 Sep 2001 19:33:04 +0100

 On Mon, Sep 03, 2001 at 03:29:39PM -0700, Bernd Luevelsmeyer wrote:
 > >Description:
 > CLOCKS_PER_SEC in the #include-file <time.h> is 128.
 > "The Single UNIX Specification" at
 > http://www.UNIX-systems.org/online.html however says
 > "CLOCKS_PER_SEC is defined to be one million in <time.h>", and
 > the Red Hat Linux 7.2 manpage says "POSIX requires
 > that CLOCKS_PER_SEC equals 1000000 independent of the actual
 > resolution."
 > >How-To-Repeat:
 > 
 > >Fix:
 > If POSIX indeed requires CLOCKS_PER_SEC to be one million then
 > it should be changed to that value, in order to enhance
 > Standard conformance.
 
 This cannot be changed without either a library version number bump
 or introducing binary incompatability. Some people also reily on
 code using CLOCKS_PER_SEC producing sensible values.
 
 	David.

From: Bruce Evans <bde@zeta.org.au>
To: Bernd Luevelsmeyer <bdluevel@heitec.net>
Cc: <freebsd-gnats-submit@FreeBSD.ORG>
Subject: Re: misc/30297: CLOCKS_PER_SEC non-standard
Date: Wed, 5 Sep 2001 04:37:25 +1000 (EST)

 On Mon, 3 Sep 2001, Bernd Luevelsmeyer wrote:
 
 > >Description:
 > CLOCKS_PER_SEC in the #include-file <time.h> is 128.
 > "The Single UNIX Specification" at
 > http://www.UNIX-systems.org/online.html however says
 > "CLOCKS_PER_SEC is defined to be one million in <time.h>", and
 > the Red Hat Linux 7.2 manpage says "POSIX requires
 > that CLOCKS_PER_SEC equals 1000000 independent of the actual
 > resolution."
 
 This is an XSI extension.  In POSIX, CLOCKS_PER_SECOND can be any
 (arithmetic) (r)value, the same as in ISO C.  Even in XSI, applications
 should not use this misfeature.  From POSIX.1-200x draft7:
 
 13691 XSI           Although the value of CLOCKS_PER_SEC is required to be 1 million on all XSI-conformant
 13692               systems, it may be variable on other systems, and it should not be assumed that
 13693               CLOCKS_PER_SEC is a compile-time constant.
 
 Constants like this shouldn't be standardized.  A resolution of only 1
 part in a million is is potentially inadequate by a factor of about 1000
 even for today's 1GHz systems.  POSIX's clock_getres() is similarly broken
 as designed.
 
 Bruce
 

From: Bernd Luevelsmeyer <bdluevel@heitec.net>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@FreeBSD.ORG,
	David Malone <dwmalone@maths.tcd.ie>
Subject: Re: misc/30297: CLOCKS_PER_SEC non-standard
Date: Tue, 04 Sep 2001 22:11:44 +0200

 Bruce Evans wrote:
 >  On Mon, 3 Sep 2001, Bernd Luevelsmeyer wrote:
 > 
 >  > >Description:
 >  > CLOCKS_PER_SEC in the #include-file <time.h> is 128.
 >  > "The Single UNIX Specification" at
 >  > http://www.UNIX-systems.org/online.html however says
 >  > "CLOCKS_PER_SEC is defined to be one million in <time.h>", and
 >  > the Red Hat Linux 7.2 manpage says "POSIX requires
 >  > that CLOCKS_PER_SEC equals 1000000 independent of the actual
 >  > resolution."
 > 
 >  This is an XSI extension.  In POSIX, CLOCKS_PER_SECOND can be any
 >  (arithmetic) (r)value, the same as in ISO C.  Even in XSI, applications
 >  should not use this misfeature.  From POSIX.1-200x draft7:
 > 
 >  13691 XSI           Although the value of CLOCKS_PER_SEC is required to be 1 million on all XSI-conformant
 >  13692               systems, it may be variable on other systems, and it should not be assumed that
 >  13693               CLOCKS_PER_SEC is a compile-time constant.
 > 
 >  Constants like this shouldn't be standardized.  A resolution of only 1
 >  part in a million is is potentially inadequate by a factor of about 1000
 >  even for today's 1GHz systems.  POSIX's clock_getres() is similarly broken
 >  as designed.
 
 
 Thanks for your explanations. I'm retracting the PR; please close
 it.
 
 Perhaps a comment in either the header file or the clock(3) man page
 might be appropriate, in order to prevent someone else from raising
 the issue again? I suggest to put it into the clock.3 "Standards"
 section.
 
 --- clock.3.old Tue Sep  4 22:02:01 2001
 +++ lib/libc/gen/clock.3     Tue Sep  4 22:04:08 2001
 @@ -69,3 +69,6 @@
  .Fn clock
  function conforms to
  .St -isoC .
 +CLOCKS_PER_SEC is not 1 million (as required by XSI), because
 +this may be inadequate even on today's 1 GHz systems, and anyway
 +it's not a POSIX requirement.
Responsible-Changed-From-To: freebsd-bugs->dwmalone 
Responsible-Changed-By: dwmalone 
Responsible-Changed-When: Tue Sep 4 13:25:47 PDT 2001 
Responsible-Changed-Why:  
The suggested comment in the man page seems reasonable to me. I'll commit 
it, unless anyone has any further comments on the matter. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=30297 

From: Bruce Evans <bde@zeta.org.au>
To: Bernd Luevelsmeyer <bdluevel@heitec.net>
Cc: <freebsd-gnats-submit@FreeBSD.ORG>,
	David Malone <dwmalone@maths.tcd.ie>
Subject: Re: misc/30297: CLOCKS_PER_SEC non-standard
Date: Thu, 6 Sep 2001 01:32:46 +1000 (EST)

 On Tue, 4 Sep 2001, Bernd Luevelsmeyer wrote:
 
 > Perhaps a comment in either the header file or the clock(3) man page
 > might be appropriate, in order to prevent someone else from raising
 > the issue again? I suggest to put it into the clock.3 "Standards"
 > section.
 >
 > --- clock.3.old Tue Sep  4 22:02:01 2001
 > +++ lib/libc/gen/clock.3     Tue Sep  4 22:04:08 2001
 > @@ -69,3 +69,6 @@
 >  .Fn clock
 >  function conforms to
 >  .St -isoC .
 > +CLOCKS_PER_SEC is not 1 million (as required by XSI), because
 > +this may be inadequate even on today's 1 GHz systems, and anyway
 > +it's not a POSIX requirement.
 >
 
 More because it would break binary compatibilty.  I wanted to change
 CLOCKS_PER_SEC to 1 million many years ago (clocks.7 says a little
 about this), but didn't want to face the binary compatibilty issues.
 clock_t would have to be int64_t or uint64_t...
 
 Bruce
 

From: Bruce Evans <bde@zeta.org.au>
To: Bernd Luevelsmeyer <bdluevel@heitec.net>
Cc: <freebsd-gnats-submit@FreeBSD.ORG>,
	David Malone <dwmalone@maths.tcd.ie>
Subject: Re: misc/30297: CLOCKS_PER_SEC non-standard
Date: Thu, 6 Sep 2001 01:48:19 +1000 (EST)

 On Thu, 6 Sep 2001, I wrote:
 
 > clock_t would have to be int64_t or uint64_t...
 
 This was because POSIX.1-199[0-6] specifies that clock_t shall be
 capable of representing all integer values from zero to the number of
 clock ticks in 24 hours.  24 hours of ticks at 1 million per seconds
 requires 37 bits to represted.  But this requirement seems to be
 broken in POSIX.1-200x.
 
 Bruce
 
State-Changed-From-To: open->closed 
State-Changed-By: dwmalone 
State-Changed-When: Sat Feb 16 06:08:53 PST 2002 
State-Changed-Why:  
Note explaining why CLOCKS_PER_SEC != 1000000 now in -current and -stable. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=30297 
>Unformatted:
