Hi Paul, (sorry for the long delay)
Le Wed, 1 Aug 2018 23:45:08 -0700, Paul Eggert <egg...@cs.ucla.edu> a écrit : > Albert ARIBAUD wrote: > > I really need you to develop in some more detail how you envision adding > > Y2038 support in Gnulib. > > It sounds like the best thing to do is the original plan: you develop a set > of > glibc patches without worrying about Gnulib, I'll suggest any necessary > changes, > and we iterate until we converge. There really isn't *that* much complexity > to > Gnulib, after all. This will require some accommodation, as you can't expect > the > resulting code to be absolutely minimal for glibc. OK, so I'll resume posting on GLIBC. Should I cross-post here? > Where is your glibc patchset now? I could take a look at it. It is available, rebased over current master, at https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/aaribaud/y2038 Notes: 1. This branch may be frequently rebased above master and/or modified to follow change requested during reviews of the Y2038 series.) 2. The first patch is probably not going to matter to Gnulib, since it introduces the __time64_t type which is used to create a Y2038-proof time_t, and Gnulib does not define time_t. Same for the last patch, which is about making the public API either stick with the 'old' time_t and related types and prototypes, or switch to the 'new' time_t etc. 3. Currently, it fails to cross-build for ARM on x86-64, but then, so does the glibc master above which it is based, and both for the same reason, unrelated to the series. Cordialement, Albert ARIBAUD 3ADEV
