Bug 30297

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.

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

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.

Comment 4 dwmalone 2001-09-04 21:25:47 UTC

Responsible Changed
From-To: freebsd-bugs->dwmalone

The suggested comment in the man page seems reasonable to me. I'll commit 
it, unless anyone has any further comments on the matter.

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

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

Comment 7 dwmalone 2002-02-16 14:08:53 UTC

State Changed
From-To: open->closed

Note explaining why CLOCKS_PER_SEC != 1000000 now in -current and -stable.