This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v2 00/10] Y2038 preparation: use clock_[gs]ettime to implement the other time-getting and -setting functions.
- From: Zack Weinberg <zackw at panix dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Florian Weimer <fweimer at redhat dot com>, Lukasz Majewski <lukma at denx dot de>, Alistair Francis <alistair23 at gmail dot com>, Stepan Golosunov <stepan at golosunov dot pp dot ru>, Arnd Bergmann <arnd at arndb dot de>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- Date: Tue, 3 Sep 2019 10:43:19 -0400
- Subject: Re: [PATCH v2 00/10] Y2038 preparation: use clock_[gs]ettime to implement the other time-getting and -setting functions.
- References: <firstname.lastname@example.org> <alpine.DEB.email@example.com>
On Wed, Aug 28, 2019 at 1:15 PM Joseph Myers <firstname.lastname@example.org> wrote:
> On Wed, 28 Aug 2019, Zack Weinberg wrote:
> > - The obsolete functions ftime and stime are no longer available to
> > new binaries. The header <sys/timeb.h> is no longer installed.
> It might be advisable to see if this affects the build of libsanitizer,
> and alert sanitizer maintainers if so. (There appear to be sanitizer
> interceptors for ftime and stime, and an include of <sys/timeb.h>.)
I may not have time to do anything about this for at least a couple
weeks, but I can confirm that the absence of sys/timeb.h does break
the build of libsanitizer. Adhemerval's suggestion of keeping ftime
and <sys/timeb.h> around for at least another release, but issuing
warnings if ftime is actually used (attribute((deprecated)) maybe?)
seems reasonable to me.