This is the mail archive of the
mailing list for the glibc project.
Re: Is Y2038-proofing in a glibc roadmap somewhere?
- From: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 3 Aug 2015 10:43:25 +0200
- 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> <alpine dot DEB dot 2 dot 10 dot 1507221418360 dot 21570 at digraph dot polyomino dot org dot uk>
Thanks for the detailed answer on how to proceed.
Le Wed, 22 Jul 2015 14:26:10 +0000, Joseph Myers
<email@example.com> a Ãcrit :
> 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.
As I don't have a copyright assignment in place with the FSF yet, the
contribution checklist copyright assignment section
says someone from libc-alpha should direct me to a FSF copyright
assignment request form that's best suited to your contribution under
the guidelines. According to
maintainers and important contributors can access the copyright papers
through their fencepost account, so obviously I don't qualify for
getting the papers myself.
Just in case, I have created a Savannah account (number 100585) with a
public SSH key 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.
Hmm, why the relationship with _FILE_OFFSET_BITS? At least at first
sight, supporting 64-bit time seems pretty unrelated/orthogonal to
supporting 64-bit file sizes.
Regarding the design document, am I right in assuming it should exist
as a Wiki page similar to, for instance,
https://sourceware.org/glibc/wiki/PrintfHooksDesign ? In that case, I
suspect I would need some editor to add me to EditorGroup.