Delivered-To: listarch-cygwin AT sourceware DOT cygnus DOT com Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com From: N8TM AT aol DOT com Message-ID: Date: Mon, 1 Feb 1999 21:30:40 EST To: Brian DOT P DOT Kasper AT notes DOT aero DOT org, gnu-win32 AT cygnus DOT com Mime-Version: 1.0 Subject: Re: B20.1 clock() function bug? Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 226 In a message dated 2/1/99 4:39:45 PM Pacific Standard Time, Brian DOT P DOT Kasper AT notes DOT aero DOT 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.