• Bug#872556: libc0.1: clock() has wrong scaling factor on hurd

    From Samuel Thibault@21:1/5 to All on Wed Aug 23 02:40:01 2017
    XPost: linux.debian.bugs.dist, linux.debian.ports.hurd

    Control: tags -1 + pending


    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

    This was originally found after debugging ffmpeg. I believe the FTBFS on
    hurd is caused by this bug.



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