Hi Bruno, Le Wed, 01 Aug 2018 15:25:59 +0200, Bruno Haible <br...@clisp.org> a écrit :
> Hello Albert, > > > Gnulib does not provide time_t > > > > and relies on the underlying system, which may or may not include GLIBC. > > Correct. > > > IIUC: > > > > * Gnulib does not *define* time_t at all, always assuming > > that it will exist in the underlying system. > > Correct. > > > * Also, Gnulib may, if module Y2038 is used, check whether time_t is > > Y2038-proof or not. > > Yes. > > > * If the underlying time_t is not Y2038-proof, Gnulib makes no effort > > to fix the situation. > > Incorrect. I explained this in > <https://lists.gnu.org/archive/html/bug-gnulib/2018-07/msg00041.html>. Maybe I misunderstood, then: for me, this explanation meant that if the architecture *could* provide a Y2038-proof time_t but only under the right circumstances (i.e., it provides a 32-bit time_t *or* a 64-bit one depending on the presence or value of some -D compiler options), then year2038 will ensure these circumstances happen (i.e., make it so that the right -D options are passed); but if the architecture does not in *any* circumstance provide a Y2038-proof time_t, then year2038 will not fix *that* by pulling a magic time_t out of a hat. > > * 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. > > Yes. But it is not possible to support a wider time_t type without kernel > support, and in Gnulib we usually don't want to be in the business of > interfacing with the kernel directly - that is the business of the libc. > Therefore a Gnulib-defined time_t type is not likely to happen. 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). But in order for Y0238 support code to go in, Gnulib will need a Y2038-proof time_t from glibc. But glibc can only provide a public Y0238-proof time_t when all its Y2038 support code is in. And I cannot put Y2038 support code in glibc before Gnulib has it. I must be missing something here. Paul, can you comment? > > * 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. > > Correct. > > > * But some Gnulib functions may need to use both the Y2038-proof time > > type and the underlying system's time type. > > This is exactly the problem. If Gnulib provides a time_t type, and since > we don't want the application code to require changes, Gnulib must also > provide wrappers or replacement for _all_ system functions that reference > a time_t type. This is a huge complexity. Well, either Gnulib provides its own time_t, or the Y2038 support code goes in glibc before it goes to Gnulib, because unless I'm missing something, those are the only two ways I can see to break the vicious circle. > I considered doing a similar thing with wchar_t on Windows platforms > (define a 32-bit wchar_t where the system one is only 16-bit), but gave > up, facing the huge complexity. I've got a 60-odd patch list for glibc at the moment, and I probably haven't covered everything, but at least it is self-contained. I fear the problem is going to get one order of magnitude more complex by introducing ordering dependencies between gnulib and glibc. > Bruno Cordialement, Albert ARIBAUD 3ADEV
