Third draft of the Y2038 design document

[Joseph Myers]

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