mcgrath@paris.Berkeley.EDU@ (Roland McGrath) (03/20/89)
Newsgroups: comp.std.c,comp.std.unix
Sender: uunet!usenet@agate.Berkeley.EDU@
From: uunet!mcgrath@paris.Berkeley.EDU@ (Roland McGrath)
Can anyone tell me why the ANSI C committee changed CLK_TCK to
CLOCKS_PER_SEC, and how this is supposed to be different than the CLK_TCK
that 1003.1 assumes the C standard defines?
They both seem to mean the number of `clock_t' increments ("clock ticks") in
one second, but ANSI has for some reason separated the two uses (for `clock'
and for POSIX `times').
--
Roland McGrath
Free Software Foundation, Inc.
roland@wheaties.ai.mit.edu, mit-eddie!wheaties.ai.mit.edu!roland
Volume-Number: Volume 16, Number 19std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (03/20/89)
From: uunet!BRL.MIL!gwyn In article <320@longway.TIC.COM> uunet!mcgrath@paris.Berkeley.EDU@ (Roland McGrath) writes: >Can anyone tell me why the ANSI C committee changed CLK_TCK to >CLOCKS_PER_SEC, and how this is supposed to be different than the CLK_TCK >that 1003.1 assumes the C standard defines? In fact they have totally different uses, and X3J11 had made a serious mistake when we used the name "CLK_TCK" for the clock()-return conversion factor. CLK_TCK was the 1984 /usr/group macro for converting values returned by times(), not clock(). 1003.1 shuffled back and forth a couple of times between ttime_t and clock_t as the type of the struct tms members, settling on clock_t which is defined by ANSI C. (I think a separate type would have been better, but we can live with this.) Then when they saw that X3J11 had defined CLK_TCK as the appropriate conversion from units of clock_t to seconds, they naturally assumed it was the same as the 1984 /usr/group usage. However, the ANSI C clock() conversion macro was not appropriate for use with struct tms members. Last-minute frantic coordination among principal members of P1003 and X3J11, including the ANSI C draft review subcommittee, resulted in X3J11 choosing a new name for the ANSI C time-conversion macro; we considered that a (borderline) "editorial change", since the intention of the committee was clearly not changed and the use of "CLK_TCK" for clock() units conversion was purely an X3J11 invention. This means that the inheritance of the name "CLK_TCK" from <time.h> that 1003.1 expected doesn't happen (at least, not in the absence of _POSIX_SOURCE), but that was considered to be an "easily fixable" matter whereas forcing the same conversion factor for both times() and clock() would have run counter to widespread existing practice. - D A Gwyn acting X3J11/P1003 liaison Volume-Number: Volume 16, Number 22
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (03/21/89)
Newsgroups: comp.std.unix From: uunet!hpfcdc.HP.COM!hp-sdd!donn (Donn Terry) CLK_TCK is usually known as HZ (which is typically 50, 60, or 100). CLOCKS_PER_SEC is used for clock() and is typically in microseconds. For a while they were both the same, which would be a problem, obviously. The committees didn't detect the problem until quite late in the cycle. Both ANSI C and POSIX are having to change as a result. The CLOCKS_PER_SEC name change was easy for X3J11; the corresponding changes in POSIX will be harder because of its status as a published standard and because it is built on ANSI C in part. Drafts of those changes exist, but have not been approved in any way. For now: sysconf() will always give the "right" answer for CLK_TCK, so use that. I'm speaking only for myself in this. Donn Terry Chair 1003.1 Volume-Number: Volume 16, Number 20
mcgrath@paris.Berkeley.EDU (Roland McGrath) (03/23/89)
From: uunet!mcgrath@paris.Berkeley.EDU (Roland McGrath) ["CLK_TCK vs. CLOCKS_PER_SEC"] - uunet!hpfcdc.HP.COM!hp-sdd!donn (Donn Terry): ) For now: sysconf() will always give the "right" answer for CLK_TCK, so ) use that. Well, I'm trying to *implement* it in my C library, so can you tell us what "unapproved in any way" but changes have been made to the standards? Thanks, Roland McGrath <roland@wheaties.ai.mit.edu> Free Software Foundation Roland McGrath Free Software Foundation, Inc. roland@wheaties.ai.mit.edu, mit-eddie!wheaties.ai.mit.edu!roland Volume-Number: Volume 16, Number 23
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (03/25/89)
[ Bob Lenk remarks that the address that various mail software
produced for him probably won't work:
> From: uunet!hpfcdc.HP.COM!hp-sdd!donn (Donn Terry)
and that these would be more likely:
donn@hpfcdc.HP.COM
uunet!hpda!hpfcdc!donn
-mod ]
Volume-Number: Volume 16, Number 24