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: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Mon, 3 Aug 2015 15:36:22 +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> <20150803104325 dot 2ec7b9ea dot albert dot aribaud at 3adev dot fr> <CAKCAbMgABZf4bU0FNu1-9bJtM3aS6mPxiZH+J5yk-EsBPReWiA at mail dot gmail dot com>
Bonjour Zack,
Le Mon, 3 Aug 2015 09:07:25 -0400, Zack Weinberg <zackw@panix.com> a
Ãcrit :
> 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
Thanks. I've sent the request accordingly.
> > 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().
I get the idea, although I am not sure why we would want to use
structure size to tell variants apart. If we know there are variants
to begin with, then we know on which macro these variants depend and we
can tell the variants apart based on which macros are defined, could
we not?
> zw
Cordialement,
Albert ARIBAUD
3ADEV