Date: Tue, 4 Sep 2001 11:40:03 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: misc/30297: CLOCKS_PER_SEC non-standard Message-ID: <200109041840.f84Ie3R12253@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR misc/30297; it has been noted by GNATS. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109041840.f84Ie3R12253>