Fwd: Fifth draft of the Y2038 design document

[Joseph Myers]

On Wed, 1 Mar 2017, Zack Weinberg wrote:

> I'm not convinced this is even _possible_, and I don't see why it's
> necessary to support old kernels _when 64-bit time_t is activated_.
> Yes, fix all the code in glibc, but why can't --enable-64-bit-time-t
> mean that the libc.so you get requires a newer kernel?

There's no such configure option.  glibc version N provides support for 
_TIME_BITS=64 where previous versions do not.  And in that glibc version, 
anything in glibc using time_t, struct timespec etc. as part of 
implementing another interface will internally use __clock_gettime64 etc., 
unconditionally (with appropriate mapping back to __clock_gettime in the 
cases where time_t is already 64-bit and so no __clock_gettime64 exists), 
just as internal code now uses __xstat64 etc. unconditionally (indeed, all 
those __xstat64 calls may need to change to call the variant for 64-bit 
times).

Having _TIME_BITS=64 interfaces that might all fail with ENOSYS, so that 
applications can't just define _FILE_OFFSET_BITS=64 _TIME_BITS=64 
unconditionally but need to test what's supported in the installed glibc 
(and, worse, the installed kernel, which can't work when cross compiling) 
is not friendly to users.

-- 
Joseph S. Myers
joseph@codesourcery.com