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: Joseph Myers <joseph at codesourcery dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 8 Jun 2016 16:58:33 +0000
- 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> <a86089b9-dfd5-d7f6-2da5-5af4c5360edc at cs dot ucla dot edu>
On Wed, 8 Jun 2016, Paul Eggert wrote:
> 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?
Functions that use time_t etc. internally need to be updated to use the
__*time64 interfaces (much like stat64 interfaces are used internally).
So they are unsafe in a different way - no new exported versions are
needed, but the implementation should be made to use new interfaces
internally.
> 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
But they still need new versions for _TIME_BITS=64, because that will make
time_t into a 64-bit type.
--
Joseph S. Myers
joseph@codesourcery.com