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: Mon, 21 Mar 2016 13:15:20 +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>
Bonjour Paul,
Le Thu, 28 Jan 2016 13:13:09 -0800, Paul Eggert <eggert@cs.ucla.edu> a
Ãcrit :
> Some typos: "1901-12-13 19:55:13 UTC" should be "1901-12-13 20:45:52
> UTC". "sentive" should be "sensitive". "20338" should be "2038". "Thins"
> should be "This".
Thanks, will fix this.
> I don't see why functions like 'time' and 'gettimeofday' should be
> allowed to misbehave on 64-bit hosts after 2038. They should just work.
> Glibc should not worry about 64-bit kernels without 64-bit time support.
> Any such kernels should just get fixed before 2038 rolls around.
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?
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?
Cordialement,
Albert ARIBAUD
3ADEV