On Sat, 2017-09-02 at 04:04 +0200, Adam Borowski wrote: > On Sat, Sep 02, 2017 at 12:58:54AM +0100, Steve McIntyre wrote: > > What's the problem? > > ------------------- > > > > UNIX time_t is 31 bits (signed), counting seconds since Jan 1, > > 1970. It's going to wrap.. It's used *everywhere* in UNIX-based > > systems. Imagine the effects of Y2K, but worse. > > Glibc is the next obvious piece of the puzzle - almost everything > > depends on it. Planning is ongoing at > > > > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign > > > > to provide 64-bit time_t support without breaking the existing 32-bit > > code. > > I find it strange that you don't mention x32 anywhere. Dealing with > assumptions that time_t = long was the majority of work with this port; a > lot of software still either did not apply submitted patches or accepted > only dumb casts to (long) instead of a proper y2038-proof solution.
AFAIK, various compat ioctl implementations assume 32-bit time_t and so don't work properly for x32. The work being done to add 64-bit time support for older 32-bit architectures will work for both i386 and x32. So x32 doesn't solve any problems. Ben. -- Ben Hutchings Life is what happens to you while you're busy making other plans. - John Lennon
signature.asc
Description: This is a digitally signed message part
