Message ID | 20190828153236.18229-1-zackw@panix.com |
---|---|
Headers | show |
Series | Y2038 preparation: use clock_[gs]ettime to implement the other time-getting and -setting functions. | expand |
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>.) After comments at last year's Cauldron about glibc API changes breaking sanitizers and language libraries such as libgo, I added a --full-gcc option to build-many-glibcs.py with the hope that the people raising such issues would set up bots to monitor for them, but I don't think anyone has set up such a bot (and there were a series of pre-existing build issues using that option, as well as the need to have a new-enough native Ada compiler in the PATH when using it).
On Wed, Aug 28, 2019 at 1:15 PM Joseph Myers <joseph@codesourcery.com> 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. zw
On 03/09/2019 11:43, Zack Weinberg wrote: > On Wed, Aug 28, 2019 at 1:15 PM Joseph Myers <joseph@codesourcery.com> 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. > > zw > Hi Zack, I just pushed a personal branch [1] based on your y2038-preliminaries with the changes I have proposed in the review: * Change most internal uses of __gettimeofday to __clock_gettime. - Some tab/whitespace issues. - Hurd time_value_t to timespec strict issues. * Use clock_settime to implement settimeofday. - Simplify sysdeps/unix/sysv/linux/settimezone.c * Use clock_gettime to implement time. - Do not remove arch-specific time implementations. - Adjust powerpc time to use the new generic implementation. * Use clock_gettime to implement ftime; withdraw ftime. - Keep the sys/timeb.h header and deprecate ftime. * Use clock_gettime to implement gettimeofday. - Do not remove arch-specific gettimeofday implementations. * Warn when gettimeofday is called with non-null tzp argument. - Remove the __warndecl hack. - Change to "Make second argument of gettimeofday as 'void *'" and adjust the required implementations. I don't like to clash with you proposal, since some changes remove some suggestion from your first patchset. [1] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/y2038-preliminaries