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

[Albert ARIBAUD]

Sorry, hit the enter key way earlier that I should have.

Le Wed, 1 Aug 2018 11:49:49 +0200, Albert ARIBAUD
<address@hidden> a écrit :

> Hi Paul,
> 
> Le Fri, 6 Jul 2018 21:45:54 -0700, Paul Eggert <address@hidden> a
> écrit :
> 
> > Bruno Haible wrote:  
> > > What would be the benefit of doing so in gnulib? That some, but not all,
> > > programs of a Linux distro can claim Y2038-proof-ness before all the 
> > > rest?    
> > 
> > Basically that, yes, though the benefit is not limited to Linux kernels. It 
> > should work for FreeBSD too. (FreeBSD i386 still hasn't decided what do to 
> > about 
> > Y2038, I think.) Admittedly this is not that high a priority.  
> 
> Let me try to sum a few things up.
> 
> Gnulib does not provide time_t

and relies on the underlying system, which may or may not include GLIBC.

Also,
 
> Let us consider the simple fact of
> having a Y2038-proof time representation.

... that is, consider only time_t, not any function which uses it; that
is, the first patch in the GLIBC Y2038 patch series.

IIUC:

 * Gnulib does not *define* time_t at all, always assuming
   that it will exist in the underlying system.

 * Also, Gnulib may, if module Y2038 is used, check whether time_t is
   Y2038-proof or not.

 * If the underlying time_t is not Y2038-proof, Gnulib makes no effort
   to fix the situation.

 * 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.

 * 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.

 * But some Gnulib functions may need to use both the Y2038-proof time
   type and the underlying system's time type.

Correct?
Cordialement,
Albert ARIBAUD
3ADEV