Subject: Re: sysconf _SC_CLK_TCK bug?
To: Perry E. Metzger <>
From: Ben Harris <>
List: tech-userlevel
Date: 06/17/2002 17:11:13
On 17 Jun 2002, Perry E. Metzger wrote:

> Ben Harris <> writes:
> > > Actually, according to the documents, it returns things in the fully
> > > unrelated CLOCKS_PER_SEC unit.
> >
> > Are you sure?
> Read the time.h thing on the opengroup web site,

<> says
(on apparently-relevant topics):

#       A number used to convert the value returned by the clock() function
#       into seconds.
#   The clock_t, size_t, time_t, [TMR] [Option Start] clockid_t, and timer_t
#   [Option End] types shall be defined as described in <sys/types.h>.
#   clock_t    clock(void);

It mentions neither "clock tick" nor times().

to which <time.h> refers for clock_t says:

#   clock_t
#       [XSI] [Option Start] Used for system times in clock ticks or
#       CLOCKS_PER_SEC; see <time.h> . [Option End]

Note the two alternatives there.

<> says:

#   To determine the time in seconds, the value returned by clock() should be
#   divided by the value of the macro CLOCKS_PER_SEC.

<>, on
the other hand, says:

#   All times are measured in terms of the number of clock ticks used.
#   Applications should use sysconf(_SC_CLK_TCK) to determine the number of
#   clock ticks per second as it may vary from system to system.

 tag_03_97> defines a "clock tick" as:

# An interval of time; an implementation-defined number of these occur
# each second. Clock ticks are one of the units that may be used to
# express a value found in type clock_t.

Note the "one of" there, implying that there's at least one other unit in
use.  Also, since the term "clock tick" is listed in the definitions, it's
fair to assume that it has the same meaning throughout the standard, and
in particular in the definitions of both sysconf() and times().

> You haven't quite got the whole picture I think.

Almost undoubtedly not, given the size of the picture in question.  I'm
not sure which relevant bits I'm lacking here though.

> > OK.  I wasn't sure that the old one could be considered to be
> > comprehensively dead just yet.
> The new one was voted in.

Heh.  My copy's actually ISO 9945-1:1996, which _hasn't_ yet been
superseded.  Point taken, though.

Even so, I think breaking applications which followed the standards that
were current when they were written and compiled is rude, especially when
our manual pages recommended this (which times(3) still does).

Ben Harris                                                   <>
Portmaster, NetBSD/acorn26           <URL:>