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:
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
--
