Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1RVKLFT0aX38fJoFejgrq7VCz7auHjtsBB9W0rwnedCw@mail.gmail.com>
Date: Tue, 7 Jun 2022 16:29:28 +0200
From: Arnd Bergmann <arnd@...nel.org>
To: musl@...ts.openwall.com
Subject: Re: Question about musl's time() implementation in time.c

On Tue, Jun 7, 2022 at 2:25 PM Zev Levy Stevenson <zevlevys@...il.com> wrote:
>
> Hi all,
>
> While running the libc-test test suite on a customized clang+musl build, I had trouble with some of the tests because of issues with time accuracy.
> I can go in detail if needed, but the problem seemed to boil down to the time() function in musl (in src/time/time.c) using a clock_gettime syscall (without vdso) instead of using the Linux time syscall that we expected it to use. Some other libc implementations use this syscall, and indeed after switching the syscall used in time () the tests passed, seemingly because the accuracy of the clocks used matched up.
> My main question is why musl's implementation doesn't use the time syscall, I'd be happy to hear if there was a special reason for this.

The time() syscall on 32-bit architectures returns a 32-bit integer,
which overflows in y2038, only
clock_gettime() has the required range.

       Arnd

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.