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

Paul Eggert wrote: 0001 and 0002 ... could be installed into Glibc now too, as they are independent of your Y2038 changes, I reworked those two patches as standalone against glibc and filed a bug report as glibc Bug#23603. See: https://sourceware.org/bugzilla/show_bug.cgi?id=23603 With thi

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

Albert ARIBAUD wrote: https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/aaribaud/y2038 Thanks for the heads-up. I would like to look at these patches sequentially. Let's start with the first three: Y2038: Add 64-bit time for all architectures Y2038: make __tz_convert compatible

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

Hi Paul, (sorry for the long delay) Le Wed, 1 Aug 2018 23:45:08 -0700, Paul Eggert 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 dev

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

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 iterat

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

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

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

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

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

> > > * If the underlying time_t is not Y2038-proof, Gnulib makes no effort > > >to fix the situation. > > > > Incorrect. I explained this in > > . > > Maybe I misunderstood, then: for me, this explanation meant that if >

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

Hi Bruno, Le Wed, 01 Aug 2018 15:25:59 +0200, Bruno Haible a écrit : > Hello Albert, > > > Gnulib does not provide time_t > > > > and relies on the underlying system, which may or may not include GLIBC. > > Correct. > > > IIUC: > > > > * Gnulib does not *define* time_t at all, always ass

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

Hello Albert, > Gnulib does not provide time_t > > and relies on the underlying system, which may or may not include GLIBC. Correct. > IIUC: > > * Gnulib does not *define* time_t at all, always assuming >that it will exist in the underlying system. Correct. > * Also, Gnulib may, if mod

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

Sorry, hit the enter key way earlier that I should have. Le Wed, 1 Aug 2018 11:49:49 +0200, Albert ARIBAUD a écrit : > Hi Paul, > > Le Fri, 6 Jul 2018 21:45:54 -0700, Paul Eggert a > écrit : > > > Bruno Haible wrote: > > > What would be the benefit of doing so in gnulib? That some, but not

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

Hi Paul, Le Fri, 6 Jul 2018 21:45:54 -0700, Paul Eggert 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 no

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

On Thu, 5 Jul 2018, Paul Eggert wrote: > 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. I don't think we should make such requests of contributers for code that is not s

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

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 h

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

[Dropping libc-alpha from CC] Hi Paul, > I was thinking of something more ambitious: having Gnulib support 64-bit > time_t on > 32-bit glibc now, even before the Glibc support is in. In doing this, it > would > emulate the planned Glibc behavior by defining the Glibc macro's name (even > tho

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

Albert ARIBAUD wrote: Do code syncs from glibc to gnulib happen on new glibc releases? It depends. Some of Gnulib syncs soon after a commit to glibc master. Other parts of Gnulib sync more lackadasically. Glibc release boundaries don't matter much. Conversely, sometimes Glibc syncs files fr

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

Bruno Haible wrote: 3) During the next source-code sync from glibc to gnulib, involving mktime.c etc., the gnulib people (likely Paul) make sure that this source code can still be used on non-glibc platforms with either 32-bit time_t or 64-bit time_t. Usually this involves a

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

Albert ARIBAUD wrote: 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 wan

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

Albert ARIBAUD wrote: I was thinking about the whole series branch that you requested for the patch series in glibc. Won't you require a similar whole series branch for gnulib? Yes, that's the idea. It shouldn't be that big a deal, for Gnulib, as Gnulib already works on both 32- and 64-bit tim

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

Bonjour Paul, Le Thu, 5 Jul 2018 12:45:30 -0700, Paul Eggert a écrit : > Albert ARIBAUD wrote: > > > Since gnulib is on Savannah, not Sourceware, I assume I will need to be > > given some level of write access to the Savannah gnulib repository in > > order to provide branches there too, similar

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

Hi Bruno, Le Thu, 05 Jul 2018 23:17:26 +0200, Bruno Haible a écrit : > Albert ARIBAUD wrote: > > 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 > >

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

Albert ARIBAUD wrote: > 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? I can't speak for Paul, but for me the sequence of steps t

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

Hi Paul, On Thu, 5 Jul 2018 12:40:07 -0700, Paul Eggert 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. > > Alt

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

Albert ARIBAUD wrote: Since gnulib is on Savannah, not Sourceware, I assume I will need to be given some level of write access to the Savannah gnulib repository in order to provide branches there too, similar to what is done in glibc. For something this small, I suggest just posting a proposed

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

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 ca

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

On Thu, Jul 5, 2018 at 2:36 PM, Albert ARIBAUD wrote: > I have had a look at gnulib in the meantime, and I would like to know > if the following assumptions are correct: I can't comment on anything else at all, but: > - gnulib does not contain any module which provides the time_t type, but > s

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

Hello all, On Wed, 27 Jun 2018 13:03:42 +0200, Albert ARIBAUD wrote : > Hi Paul, > > On Mon, 25 Jun 2018 16:56:14 -0700, Paul Eggert > wrote : > > > On 06/25/2018 03:32 PM, Albert ARIBAUD wrote: > > > I replaced the original 32-bit difftime with a wrapper > > > around the 64-bit time; and i