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

[Albert ARIBAUD]

Hi Paul,

Le Wed, 1 Aug 2018 11:49:39 -0700, Paul Eggert <address@hidden> 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