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

[Paul Eggert <eggert at cs dot ucla dot edu>]

On 06/20/2018 01:55 PM, Albert ARIBAUD wrote:
> > > This change batch creates a __difftime64 compatible with 64-bit time,
> > > and makes difftime either an alias of it or a 32-bit wrapper around it.
> > Since no glibc code calls difftime, can we assume that a later patch
> > will change will make __difftime64 and difftime both available to user
> > code? I'm not getting the big picture here.
> Actually, this is not an assumption

In that case, I'm still puzzled about the specific example of difftime. 
Are you assuming that glibc can export just one difftime function to 
32-bit user code, and that because every 32-bit time_t value fits into 
__time64_t this single function will work with both time_t and 
__time64_t? That assumption fails in many platforms (as they use 
different calling conventions for 32-bit versus 64-bit integers), so in 
general a glibc implementation on a platform that currently has 32-bit 
time_t will need to export two difftime entry points.

> What actually happened is, I am getting quite more feedback now than I
> got with the RFCs.

That's a good sign. You're getting feedback now. Many patches languish 
nearly forever because nobody has the time to review them, unfortunately.

> I'll provide two branches for reviewers

Thanks, please let us know when they're ready. That will help me answer 
questions like the difftime question above.

> We do currently have unsigned 32-bit time_t implementations, but do we
> have unsigned 64-bit time_t? A signed 64-bit integer __time64_t was
> a core assumption

That can be a core assumption of glibc, but for code shared with Gnulib 
we'd rather not make assumptions like that. It's little trouble to 
support unsigned 64-bit (or even wider) time_t in Gnulib code, and we 
should continue to support this. All we should need to assume is that 
every time_t value fits into __time64_t. Come to think of it, __time64_t 
will be a misnomer in Gnulib since __time64_t is not necessarily a 
64-bit type, so perhaps code shared with Gnulib should continue to use 
the name "internal_time_t" (for internal use only, of course) to 
underscore the fact that it might not be 64 bits.

> If the proposed patches are OK, then the best is to apply them to
> master and I will remove the corresponding ones from the Y2038 series

I don't think we're ready to start installing these into master, since I 
still don't fully understand how difftime (much less mktime) will work. 
Also, I want to make sure that the patches will be compatible with 
Gnulib. It may make more sense to change Gnulib first, as it is less 
formal about this sort of update.