Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof

[Albert ARIBAUD <albert dot aribaud at 3adev dot fr>]

Hi Zack,

On Fri, 8 Sep 2017 12:19:08 -0400, Zack Weinberg <zackw@panix.com>
wrote :

> On Thu, Sep 7, 2017 at 7:21 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> > General observations on this patch series:  
> 
> I concur with all of Joseph's observations and would add:
> 
> > * You need to make sure that new ABIs are not added / used on platforms
> > where time_t is already 64-bit.  
> 
> Elaborating on this, when time_t is already 64 bits, defining
> _TIME_BITS=64 should have no effect on the generated code, and
> defining _TIME_BITS=32 should cause a compile-time error.

Will add.

> * We are not going to land these patches until the kernel side is
> finalized.  All of the places where you have "// TODO: implement after
> the kernel does" must be replaced with an actual implementation.
> Likewise, we need a complete implementation for all supported
> architectures before landing.  You're not on the hook to implement
> this feature for the Hurd, but you should coordinate with Samuel
> Thibault so that at least you do not make glibc-for-Hurd more broken
> than it already is.

Regarding whether the patches should land only once the kernel is
Y0238-safe: these patches are intended to run even on a current and thus
completely Y2038-unsafe kernel, in which case they use 64-bit-time on
user side (to make applications compiled with _TIME_BITS==64 happy at
least until Y2038 happens) and 32-bit time on kernel side. So I don't
see why these patches should wait for a Y2038-safe kernel per se.

Re the TODOs: note that right now, all these TODOs are coded in such a
way that the implementation "falls through" to using 32-bit syscalls or
code, just like it would if running on an older kernel.

> (But I would encourage you to create a named branch in glibc git for
> this project if you haven't already, to make it easier for others to
> experiment with it.)

There is such a branch, mentioned in the implementation part of the
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign document.

> * I understand that you are trying to make the transition as seamless
> as possible with _TIME_BITS and so on, but I would seriously question
> whether it is appropriate to preserve super-legacy APIs such as
> 'stime' and 'utime' in the extended mode.  (I'd put the cutoff at
> 'gettimeofday', which is still heavily used even though
> 'clock_gettime' officially supersedes it.)

I'm all for not adding 64-bit-time versions of APIs which are obsolete.
The patch series is organized to facilitate removing or adding types and
functions.

As to which APIs should be made obsolete, there appears to be room for
debate.

I will add a section in the design document listing obsolete(d) APIs
(there are a few which are tagged as such, but not in a section of
their own yet) and as consensus emerges, I will update the patch series
and document.

> * The POSIX (and ISO C now, argh) requirement for tv_nsec to be 'long'
> is, as discussed at great length earlier, incorrect and should be
> ignored.  It should instead be a new typedef 'nsec_t' available in
> <sys/types.h>, matching the kernel's choice of 32 or 64 bits for this
> field (all _t names are reserved for future extension, so the typedef
> doesn't need to be _GNU_SOURCE-only). This "willful violation" (as the
> HTML5 folks put it) must, of course, be documented.

(seems to be a topic for debate)

> * We do not use Signed-off-by: and we actively want you to _not_
> include it in your patch submissions.  (We have the FSF-mandated
> actual copyright assignments instead.)

Will fix.

> * The patch series is split too finely.  I recommend breaking it up by
> type instead of by function -- time64_t + all the functions that use
> only time64_t; struct timeval64 + all the functions that use only
> time64_t and/or struct timeval64; and so on.

As indicated above, I broke it up by type and function (except when
dependencies made it really impractical) to easy adding or removing (and
reviewing) individual functions. 50-odd patches are manageable IMO, but
maybe some people may be put off by it... What I'll do is keep two
branches: this fine-grained one, and a coarser-grained one where all
changes related to one type are grouped. Best of both worlds.

> zw

Thanks for your review!

Cordialement,
Albert ARIBAUD
3ADEV