Re: [PATCH 1/1] Y2038: add function __difftime64

[Albert ARIBAUD]

Hi Bruno,

Le Wed, 01 Aug 2018 15:25:59 +0200, Bruno Haible <address@hidden> 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