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.
