This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Is Y2038-proofing in a glibc roadmap somewhere?
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 22 Jul 2015 14:26:10 +0000
- Subject: Re: Is Y2038-proofing in a glibc roadmap somewhere?
- Authentication-results: sourceware.org; auth=none
- References: <20150618150835 dot 315775b7 dot albert dot aribaud at 3adev dot fr> <20150618132533 dot GG22285 at port70 dot net> <20150618154948 dot 714738c2 dot albert dot aribaud at 3adev dot fr> <20150709100932 dot 3dd2cbf7 dot albert dot aribaud at 3adev dot fr>
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