This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Third 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>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 8 Jun 2016 09:29:08 -0700
- Subject: Re: Third draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20160608155858 dot 7cd5be27 dot albert dot aribaud at 3adev dot fr>
On 06/08/2016 06:58 AM, Albert ARIBAUD wrote:
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=63
Thanks, some comments:
The "Scope" section should clearly say that the document is only about
Y2038 (and Y1901) and is not about other time boundaries, e.g., Y2106
for unsigned 32-bit times, Y9999 for decimal years, etc. For example,
asctime_r in practice might not be Y9999-safe because it may overrun a
too-small output buffer, but this document doesn't care about Y9999 so
it marks asctime_r as Y2038-safe.
The definitions of 32- and 64-bit time should explicitly say what
happens during a leap second. In POSIX leap seconds are ignored; glibc
allows you to set TZ to a value where the time stamps also count leap
seconds. Although the rest of the document assumes leap seconds are
ignored, I assume its scope also includes TZ settings enabling leap
second support; this should be made clear.
Some of the API functions are marked as Y2038-safe merely because they
use a Y2038-safe API. However, in practice they may not work after 2038
because they use time_t internally. For example, strftime and getdate_r
call mktime and so may not work after 2038. Shouldn't these functions be
considered unsafe?
Some of the API symbols use time_t as a relative value, not as an
absolute one. These APIs should still work fine after 2038. It is true
that the APIs cannot specify relative values greater than 68 years or
so, but this is a different issue (much as the Y2106 problem is a
different issue). To limit the document's scope, I suggest excluding
these symbols; but even if we decide to fold this different problem into
the Y2038 document, the distinction should be made clear. These
functions include nanosleep, setitimer, getitmer, struct itimerval,
select, struct rusage, getrusage, struct vtimes, vtimes (and if we list
'select', why not pselect?) Also, shouldn't rlim_t and
sched_rr_get_interval be in the same camp as these?