XPost: linux.debian.bugs.dist, linux.debian.ports.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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)