This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Third draft of the Y2038 design document


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]