bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Albert ARIBAUD
Subject: Re: [PATCH 1/1] Y2038: add function __difftime64
Date: Fri, 31 Aug 2018 17:04:13 +0200

Hi Paul,

(sorry for the long delay)

Le Wed, 1 Aug 2018 23:45:08 -0700, Paul Eggert
<address@hidden> a écrit :

> Albert ARIBAUD wrote:
> > I really need you to develop in some more detail how you envision adding
> > Y2038 support in Gnulib.  
> 
> It sounds like the best thing to do is the original plan: you develop a set 
> of 
> glibc patches without worrying about Gnulib, I'll suggest any necessary 
> changes, 
> and we iterate until we converge. There really isn't *that* much complexity 
> to 
> Gnulib, after all. This will require some accommodation, as you can't expect 
> the 
> resulting code to be absolutely minimal for glibc.

OK, so I'll resume posting on GLIBC. Should I cross-post here?

> Where is your glibc patchset now? I could take a look at it.

It is available, rebased over current master, at

https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/aaribaud/y2038

Notes:

1. This branch may be frequently rebased above master and/or
   modified to follow change requested during reviews of the Y2038
   series.)

2. The first patch is probably not going to matter to Gnulib, since it
   introduces the __time64_t type which is used to create a Y2038-proof
   time_t, and Gnulib does not define time_t. Same for the last patch,
   which is about making the public API either stick with the 'old'
   time_t and related types and prototypes, or switch to the 'new'
   time_t etc.

3. Currently, it fails to cross-build for ARM on x86-64, but then, so
   does the glibc master above which it is based, and both for the
   same reason, unrelated to the series.

Cordialement,
Albert ARIBAUD
3ADEV



reply via email to

[Prev in Thread] Current Thread [Next in Thread]