This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fwd: Fifth draft of the Y2038 design document
- 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>
- Date: Wed, 1 Mar 2017 20:52:28 -0500
- Subject: Re: Fwd: Fifth draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20170222090511.48be22ed.albert.aribaud@3adev.fr> <alpine.DEB.2.20.1702221647560.8704@digraph.polyomino.org.uk> <20170222194855.7581deca.albert.aribaud@3adev.fr> <alpine.DEB.2.20.1702222055440.24643@digraph.polyomino.org.uk> <20170223131634.06fa476c.albert.aribaud@3adev.fr> <alpine.DEB.2.20.1702231418320.15395@digraph.polyomino.org.uk> <20170223165052.1b494e3a.albert.aribaud@3adev.fr> <20170301081119.51cf96bb.albert.aribaud@3adev.fr> <CAKCAbMiuB7Au_x=AG-RSvLMaz7XEmQbRcevLbZZn13HxaJ9KUQ@mail.gmail.com> <alpine.DEB.2.20.1703011852200.20874@digraph.polyomino.org.uk> <CAKCAbMj6nZBwVZ2CWVutACLnJLM=6Ev3BXHTJCgMvSPQ7fiTig@mail.gmail.com> <CAKCAbMgcctAXihzkmH6EYABNHuveNirr=7NmggzeiXLGsvAG=A@mail.gmail.com> <alpine.DEB.2.20.1703020145460.27707@digraph.polyomino.org.uk>
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