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: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 21 Mar 2016 11:19:18 -0700
- 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>
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.
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)?
PS. Did I mention the amusing limit hardcoded into zic? It refuses to accept
time stamps before the Big Bang....