Re: Bug#872556: libc0.1: clock() has wrong scaling factor on hurd
Control: tags -1 + pending
Hello,
James Cowgill, on ven. 18 août 2017 14:32:05 +0100, wrote:
> The clock() function on hurd has the wrong scaling factor.
Ok, it seems the confusion is due to this (from times(2) manual):
“Note that clock(3) also returns a value of type clock_t, but this
value is measured in units of CLOCKS_PER_SEC, not the clock ticks used
by times().”
So AIUI, we should drop the clock.c part of the
unsubmitted-clock_t_centiseconds.diff patch. That will fix your
testcase, and I believe will not break guile-2.0.
> While I appreciate that hurd's clock may not be able to be as precise as
> on Linux,
Actually this notion is extremely vague. Linux used to be at 100Hz, then
1000Hz, then variable frequency or even no frequency. It happens that
gnumach stayed at 100Hz.
Now, Linux just always exposes CLK_TCK as 100 to userland, whatever its
actual frequency, thus applications assuming that. And CLOCKS_PER_SEC is
defined to 1000000 by POSIX, whatever the actual precision.
> The patch header contains a description about applications failing with
> high precision. IMHO those applications are broken. Their bugs should
> not be worked around in libc and that patch should be dropped.
In an ideal world, yes. In the real world we are tired of submitting
patches to all kinds of applications with all kinds of bug submission
procedures, etc. while merely behaving like Linux (i.e. lying) just
"works".
> This was originally found after debugging ffmpeg. I believe the FTBFS on
> hurd is caused by this bug.
Cool!
Thanks,
Samuel
Reply to: