David, Andrew, Paul, A late coda to this thread, but I'll just note some changes I'm making to the man page (which I'd like you to review -- please see below), and note a few other points.
Andrew, you asked about what happens for x86 with the -1 to -4095 return for other syscalls. At least two other syscalls suffer the same problem. >From the fcntl(2) man page: BUGS A limitation of the Linux system call conventions on some architectures (notably x86) means that if a (negative) process group ID to be returned by F_GETOWN falls in the range -1 to -4095, then the return value is wrongly interpreted by glibc as an error in the system call; that is, the return value of fcntl() will be -1, and errno will contain the (positive) process group ID. Some testing just now shows me that lseek() on /dev/mem suffers similar problems when seeking to bytes 0xfffff001 through to 0xffffffff. Ulrich Drepper wrote: > Chris Friesen wrote: >>> A possible remedy is to return the ticks since process start time, which >>> delays the wrap around much further. POSIX only demands consistency >>> within the same process. >> This would be an interesting solution. > >> The man page for linux states that the return code is time since system >> boot, so that could realistically be expected to correlate between >> different processes. > > The Linux man page is documenting existing functionality on top of what > the standard requires. Programmers should ever only require what the > standard guarantees. > > I am perfectly willing to support a solution where the time is measured >>from process startup time. The only code using times() I found is > cross-platform and most likely does not depend on the value returned is > usable in isolation (only in a difference). Did I miss anything? Is anyone actually working on a solution along these lines? In the meantime, for man-pages-2.74, I've reworked the description of the return value: RETURN VALUE times() returns the number of clock ticks that have elapsed since an arbitrary point in the past. The return value may overflow the possible range of type clock_t. On error, (clock_t) -1 is returned, and errno is set appropriately. I moved the Linux specific details of the return value to NOTES, and added a warning about relying on those details: NOTES ... On Linux, the "arbitrary point in the past" from which the return value of times() is measured has varied across kernel versions. On Linux 2.4 and earlier this point is the moment the system was booted. Since Linux 2.6, this point is (2^32/HZ) - 300 (i.e., about 429 million) sec- onds before system boot time. This variability across kernel versions (and across Unix implementations), com- bined with the fact that the returned value may overflow the range of clock_t, means that a portable application would be wise to avoid using this value. To measure changes in elapsed time, use gettimeofday(2) instead. Under BUGS I added: BUGS A limitation of the Linux system call conventions on some architectures (notably x86) means that on Linux 2.6 there is a small time window (41 seconds) soon after boot when times(2) can return -1, falsely indicating that an error occurred. The same problem can occur when the return value wraps passed the maximum value that can be stored in clockid_t. Look okay to you folks? Cheers, Michael -- Michael Kerrisk Maintainer of the Linux man-pages project http://www.kernel.org/doc/man-pages/ Want to report a man-pages bug? Look here: http://www.kernel.org/doc/man-pages/reporting_bugs.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/