This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Second draft of the Y2038 design document
- From: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 25 Mar 2016 13:24:40 +0100
- Subject: Re: Second draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20160128204114 dot 6c7dbbf7 dot albert dot aribaud at 3adev dot fr> <56AA8465 dot 5040803 at cs dot ucla dot edu> <20160321131520 dot 6c27251e dot albert dot aribaud at 3adev dot fr> <56F03B26 dot 9020704 at cs dot ucla dot edu>
Bonjour Paul,
Le Mon, 21 Mar 2016 11:19:18 -0700, Paul Eggert <eggert@cs.ucla.edu> a
Ãcrit :
> Albert ARIBAUD wrote:
> > What about using GLIBC used over a current 64-bit kernel version, which
> > does not have proper Y2038 support, which makes GLIBC unable to provide
> > correct time-of-day past Y2038?
>
> We're saying "don't do that".
>
> > Should this GLIBC/kernel version combination be considered forbidden,
> > IOW, are we saying a Y2038-proof GLIBC should only be used with a
> > Y2038-proof kernel?
>
> No, we're saying that if your kernel has a Y2038 bug, the resulting system has a
> Y2038 bug. That doesn't mean you can't run a Y2038-safe glibc atop the buggy kernel.
Which is fine; obviously I'll rephrase the document to that effect.
> By the way, a common problem with 64-bit kernels is not Y2038, it's something
> trickier, e.g., arbitrary limits at 2**63 / 1000000 because someone naively used
> a 64-bit microsecond counter. These limits are often well past 2038, but they
> don't have to be. Are you worried about all arbitrary time limits before 2**63,
> or just time limits that show up by 2038? For example, how about the time limit
> 2**32 (in the year 2106)?
I am primarily tasked to work on fixing the Y2038 issue. I might also
fix some othern non-Y2038-related, time limits on a case-by-case basis,
but priority goes to Y2038.
> PS. Did I mention the amusing limit hardcoded into zic? It refuses to accept
> time stamps before the Big Bang....
:D
Cordialement,
Albert ARIBAUD
3ADEV