Sorry, hit the enter key way earlier that I should have. Le Wed, 1 Aug 2018 11:49:49 +0200, Albert ARIBAUD <albert.arib...@3adev.fr> a écrit :
> Hi Paul, > > Le Fri, 6 Jul 2018 21:45:54 -0700, Paul Eggert <egg...@cs.ucla.edu> a > écrit : > > > Bruno Haible wrote: > > > What would be the benefit of doing so in gnulib? That some, but not all, > > > programs of a Linux distro can claim Y2038-proof-ness before all the > > > rest? > > > > Basically that, yes, though the benefit is not limited to Linux kernels. It > > should work for FreeBSD too. (FreeBSD i386 still hasn't decided what do to > > about > > Y2038, I think.) Admittedly this is not that high a priority. > > Let me try to sum a few things up. > > Gnulib does not provide time_t and relies on the underlying system, which may or may not include GLIBC. Also, > Let us consider the simple fact of > having a Y2038-proof time representation. ... that is, consider only time_t, not any function which uses it; that is, the first patch in the GLIBC Y2038 patch series. IIUC: * Gnulib does not *define* time_t at all, always assuming that it will exist in the underlying system. * Also, Gnulib may, if module Y2038 is used, check whether time_t is Y2038-proof or not. * If the underlying time_t is not Y2038-proof, Gnulib makes no effort to fix the situation. * Making Gnulib Y2038-proof would require (for starters) providing a Y2038-proof time type to application code. * This would be done by modifying the existing Y2038 module. * Contrary to the GLIBC case, there would be no need to provide the 'new' type alongside an 'old' one to application code; only the 'new' type would be presented. * But some Gnulib functions may need to use both the Y2038-proof time type and the underlying system's time type. Correct? Cordialement, Albert ARIBAUD 3ADEV
