This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Is Y2038-proofing in a glibc roadmap somewhere?

Bonjour Zack,

Le Mon, 3 Aug 2015 09:07:25 -0400, Zack Weinberg <> a
Ãcrit :

> On Mon, Aug 3, 2015 at 4:43 AM, Albert ARIBAUD <> wrote:
> > 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.
> Since you haven't done any work yet, you want the "past and future
> changes" form:

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]