Hi Paul, Le Wed, 1 Aug 2018 11:49:39 -0700, Paul Eggert <egg...@cs.ucla.edu> a écrit :
> Albert ARIBAUD wrote: > > Hm... I fear that there's a vicious circle here: Paul wants Y2038 > > support code to go into Gnulib before it goes to glibc (for that part > > of the code which exists in both, of course). > > Yes. > > > But in order for Y0238 > > support code to go in, Gnulib will need a Y2038-proof time_t from > > glibc. > > No, that's not needed. Perhaps Gnulib can exercise the Y2038-safe support > code > on non-glibc platforms. Or perhaps the code can go into Gnulib even though > it's > never exercised on any platform (in this case we are testing that the code > won't > break anything). So we should be able to put this code into Gnulib now, even > if > glibc doesn't have a 64-bit time_t yet. There certainly should be no circular > dependency here. Regarding non-glibc platforms: I have to handle one amount of complexity to handle with just making the GLIBC Y2038-proof, and injecting Gnulib to the mix adds an whole new level of complexity. I don't think it is reasonable to add yet more complexity by adding a non-glibc platform in the mix. And I'm not even sure if that would be feasible, because the non-glibc platform we'd choose would have to be 32 bit *and* with Y2038 support. Is there one? Regarding adding the code to Gnulib without exercizing it: there's no benefit in it, as dding the code directly to glibc or going through Gnulib would result in the same untested code hitting glibc. I really need you to develop in some more detail how you envision adding Y2038 support in Gnulib. Cordialement, Albert ARIBAUD 3ADEV
