Is Y2038-proofing in a glibc roadmap somewhere?

[Joseph Myers]

On Thu, 9 Jul 2015, Albert ARIBAUD wrote:

> I'll take this as a no. :)
> 
> I will therefore start working on it myself, based on Arnd's input.
> 
> I intend to make my work available on a regular basis, probably as a git
> repo as well as (RFC) patches to this list. Is this ok?

First, please see the contribution checklist on the wiki.  In particular, 
you should make sure your copyright assignment is in place at an early 
stage; glibc reviewers are unlikely to want to look at all at any 
substantial changes without an assignment in place.

Second, I advise starting by posting an extended design document 
describing your proposed design and how various issues will be addressed, 
to avoid expending large amounts of work on an approach with fundamental 
design issues.  I think the basic requirements are clear - a macro 
_TIME_BITS=64, that is only accepted in conjunction with 
_FILE_OFFSET_BITS=64, that causes affected functions and types to be 
mapped to versions using 64-bit time_t, while keeping all existing ABIs 
as-is; that is necessitated by the basic requirement of keeping full 
compatibility with all existing binaries.  But you need to expand that 
summary from sentence length to essay length, making a thorough analysis 
of all the issues involved.

-- 
Joseph S. Myers
joseph@codesourcery.com