This is the mail archive of the cygwin@sourceware.cygnus.com
mailing list for the Cygwin project. See the Cygwin
home page for more information.
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]
Re: B20.1 clock() function bug?
- To: Brian.P.Kasper@notes.aero.org, gnu-win32@cygnus.com
- Subject: Re: B20.1 clock() function bug?
- From: N8TM@aol.com
- Date: Mon, 1 Feb 1999 21:30:40 EST
- Delivered-To: listarch-cygwin@sourceware.cygnus.com
- Delivered-To: mailing list cygwin@sourceware.cygnus.com
- Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
In a message dated 2/1/99 4:39:45 PM Pacific Standard Time,
Brian.P.Kasper@notes.aero.org writes:
<< This makes sense, as when I checked K&R (as you suggested below,
oops, shoulda done that first off), clock() is defined as
"clock returns the processor time used by the program since the
beginning of execution, or -1 if unavailable. clock()/CLK_TCK
is a time in seconds." >>
That must be the classic K&R. Since we're getting historic, I'll note that
H&S 2 quotes CLK_TCK as "proposed ANSI" while H&S 3 drops all mention of
CLK_TCK and quotes CLOCKS_PER_SECOND as the "ANSI facility."
If you're interested in gettimeofday(), it appears to have 1 second resolution
in some of the gcc ports, but I have never seen a gcc where it didn't work at
least to that extent, although that removes any advantage over standard C time
functions.
I don't know whether there is any future in trying to get fractional second
real time in a portable way; on both W95 and NT the file stamp times
sometimes run backwards by up to 2 seconds. I do find it strange that Irix
Fortran doesn't fill in the milliseconds field in DATE_AND_TIME(), when
gettimeofday() does it fine, and, as a consequence, so does g77.