This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Is Y2038-proofing in a glibc roadmap somewhere?
- From: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- To: libc-alpha at sourceware dot org
- Date: Thu, 9 Jul 2015 10:09:32 +0200
- Subject: Re: Is Y2038-proofing in a glibc roadmap somewhere?
- Authentication-results: sourceware.org; auth=none
- References: <20150618150835 dot 315775b7 dot albert dot aribaud at 3adev dot fr> <20150618132533 dot GG22285 at port70 dot net> <20150618154948 dot 714738c2 dot albert dot aribaud at 3adev dot fr>
Bonjour Albert,
Le Thu, 18 Jun 2015 15:49:48 +0200, Albert ARIBAUD
<albert.aribaud@3adev.fr> a Ãcrit :
> Hi Szabolcs,
>
> Le Thu, 18 Jun 2015 15:25:33 +0200, Szabolcs Nagy <nsz@port70.net> a
> Ãcrit :
>
> > * Albert ARIBAUD <albert.aribaud@3adev.fr> [2015-06-18 15:08:35 +0200]:
> > >
> > > I have read https://sourceware.org/glibc/wiki/HomePage especially
> > > sections 5.9.1 (Project TODO) and 5.10 (Project Wishlist by Developer)
> > > and found no indication that Y2038-proofing glibc was on any roadmap for
> > > glibc. Is it really not, or did I just miss it?
> > >
> >
> > because it is a kernel issue and glibc cannot do much until
> > the problematic syscall abis can handle 64bit time_t
> >
> > for current state of the linux kernel side see
> > https://sourceware.org/ml/libc-alpha/2015-05/msg00430.html
> > http://lwn.net/Articles/643407/
>
> Thanks -- I am already aware of Arnd Bergmann's patch series --
> actually, I've discussed with him outside this list.
>
> Of course one cannot make glibc y2038-proof before the kernel is, but I
> was not asking if anyone was working on y2038 already, only if anyone
> had any plans about working on y2038 in glibc once a suitable kernel
> is available. Sorry for the misunderstanding.
>
> So... Does anyone around know of any plans already for making glibc
> y2038-proof? :)
I'll take this as a no. :)
I will therefore start working on it myself, based on Arnd's input.
I intend to make my work available on a regular basis, probably as a git
repo as well as (RFC) patches to this list. Is this ok?
Cordialement,
Albert ARIBAUD
3ADEV