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: Zack Weinberg <zackw at panix dot com>
- To: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Cc: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Mon, 3 Aug 2015 09:07:25 -0400
- 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> <20150803104325 dot 2ec7b9ea dot albert dot aribaud at 3adev dot fr>
On Mon, Aug 3, 2015 at 4:43 AM, Albert ARIBAUD <albert.aribaud@3adev.fr> wrote:
> As I don't have a copyright assignment in place with the FSF yet, the
> contribution checklist copyright assignment section
> (https://sourceware.org/glibc/wiki/Contribution%20checklist#FSF_copyright_Assignment)
> 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.
Since you haven't done any work yet, you want the "past and future
changes" form:
http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
> According to
> http://www.gnu.org/prep/maintain/maintain.html#Copyright-Papers only
> maintainers and important contributors can access the copyright papers
> through their fencepost account, so obviously I don't qualify for
> getting the papers myself.
This is somewhat out of date - the process used to be more
complicated. Just fill out the form above and mail it in as
instructed.
> 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.
I don't know for certain what Joseph had in mind, but I believe that's
just to cut down on the number of combinations the header files need
to support. 'struct stat', for instance, contains both time_t and
off_t quantities, so there would have to be four different definitions
of it if _FILE_OFFSET_BITS and _TIME_BITS were independent, but only
three if _TIME_BITS=64 requires _FILE_OFFSET_BITS=64. And restricting
it to three variants also makes it more likely that the different
structures can be told apart by sizeof().
zw