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

[Albert ARIBAUD]

Hi Paul,

On Thu, 5 Jul 2018 12:40:07 -0700, Paul Eggert <address@hidden>
wrote :

> Albert ARIBAUD wrote:
> > I would like to know
> > if the following assumptions are correct:
> > 
> > - gnulib contains a year2038 module which is only intended to check
> >    whether time_t is limited to Y2038 or not.  
> 
> Although true for now, in the long run year2038 could be changed to enable 
> macros that will cause the implementation to use 64- instead of 32-bit 
> time_t. 
> This is a plausible thing to do once glibc has such a macro.

Now I'm confused. I was under the impression that you wanted the
64-bit-time stuff to go in gnulib before it went in glibc, so I don't
get what the "once glibc has such a macro" means. Can you elaborate on
what you had in mind?

> > - gnulib does not provide difftime either, so ATM a difftime patch
> >    would only make sense in glibc, not gnulib.  
> 
> Although Gnulib hasn't needed a difftime module yet, it might need one once 
> this 
> 32- vs 64-bit time_t stuff lands into glibc, so let's keep difftime.c usable 
> for 
> Gnulib.

Ditto.

> > - gnulib ... makes no assumption that it will be compiled into a shared 
> > object
> >    form which will provide the same functionalities for both 64-bit and
> >    32-bit callers.  
> 
> Although that's generally true, Gnulib can be used in such shared objects by 
> compiling it twice (once for each model), using different names for each 
> entry 
> point. I vaguely recall some people doing this sort of thing for 32- vs 
> 64-bit 
> file offsets, though I don't recommend the practice myself.

OK, so taking mktime as an example since gnulib provides it, and
assuming a platform where time_t is not currently Y2038-proof, if I
wanted to have a Y2038-proof mktime implementation in addition to
the existing non-Y2038-proof one, I could compile mktime.c twice, once
with the native non-Y2038-proof time_t and one with a redefined
Y2038-proof time_t and with mktime #defined to another name to avoid
having the mktime symbol defined twice.

(but I don't see yet how this is going to help making glibc Y2038-proof.
As far as I understand, glibc does not use gnulib and I don't think its
build system ever compiles a single C source file into two object files
for two different word sizes anyway).

Cordialement,
Albert ARIBAUD
3ADEV