This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/6] y2038: Use __clock_settime64 in deprecated stime function
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Lukasz Majewski <lukma at denx dot de>
- Cc: Joseph Myers <joseph at codesourcery dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, Samuel Thibault <samuel dot thibault at ens-lyon dot org>, Alistair Francis <alistair23 at gmail dot com>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at gotplt dot org>, Florian Weimer <fweimer at redhat dot com>, Florian Weimer <fw at deneb dot enyo dot de>, Zack Weinberg <zackw at panix dot com>, Carlos O'Donell <carlos at redhat dot com>, Andreas Schwab <schwab at suse dot de>
- Date: Tue, 21 Jan 2020 14:16:05 -0300
- Subject: Re: [PATCH 1/6] y2038: Use __clock_settime64 in deprecated stime function
- References: <20200118072047.23071-1-lukma@denx.de> <20200118072047.23071-2-lukma@denx.de> <44990891-a263-28c8-1b80-339864a7a95b@linaro.org> <20200120185805.2bfc8ba9@jawa> <99aa206e-c8dd-8245-b0dd-8d287bed19ef@linaro.org> <20200121175457.308aad78@jawa>
On 21/01/2020 13:54, Lukasz Majewski wrote:
> Hi Adhemerval,
>>> To have this system Y2038 safe - one needs to call
>>> __clock_settime64 explicitly to support passing arguments via
>>> struct __timespec64.
>>>
>>> This is true for all calls of __clock_settime/__clock_gettime
>>> (functions to be used internally by glibc, as we ought to switch
>>> to e.g. struct __timespec64).
>>
>> The idea of deprecate and make stime a compat symbol is exactly to
>> avoid need to provide a Y2038 version of it. Newer programs that aim
>> to be Y2038 safe will need to use clock_settime instead.
>
> I've noted that stime is marked as "deprecated". If we can agree that
> it will be removed from glibc soon (or at least before Y2038 :-)) or we
> explicitly state that it will NOT be Y2038 safe, then indeed this patch
> is not needed.
The stime prototype is not exported any longer, so newer programs trying
to use it against a future glibc with 64 bit time_t support will fail. We
can't remove compatibility symbols, so the only case I see that Y2038 safe
program to incorrectly use stime would be it define it itself with a
wrong signature (stime (time64_t)), which is outside the scope on how
glibc can mitigate it.