Fwd: Fifth draft of the Y2038 design document

[Zack Weinberg]

On Wed, Mar 1, 2017 at 8:46 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 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.

... Why do you insist that there is no such configure option?  Version
N provides _TIME_BITS=64 support *if* --enable-64-bit-time-t is used,
and that requires the presence of a newer kernel at runtime.  (Should
make a point of bombing out early in ld.so initialization.)

Yes, lots of ifdefs, but I reiterate that I am not convinced any
alternative is even _possible_.  To fall back to clock_gettime (the
system call) at runtime, when clock_gettime64 (again, the system call)
fails with ENOSYS, would require copying arguments.  That's not a
problem for clock_gettime, but it *is* potentially a problem for
ioctl, sendmsg, etc.  Witness the sendmsg-socklen_t-vs-size_t patches
that had to be scrapped.

> 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.

True.  Much friendlier to fail to link when using the glibc that still
supports the old kernels.

zw