This is the mail archive of the libc-alpha@sourceware.org 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: [PATCH 1/1] Y2038: add function __difftime64


Albert ARIBAUD wrote:
> I was under the impression that you wanted the
> 64-bit-time stuff to go in gnulib before it went in glibc, so I don't
> get what the "once glibc has such a macro" means. Can you elaborate on
> what you had in mind?

I can't speak for Paul, but for me the sequence of steps that produces the
desired result with the least effort would be:

  1) glibc implements the 'time_t' type that depends on the value _TIME_BITS
     defined at preprocessor level, like you described. Including support for
     'gettimeofday', 'stat', 'fstat' and the like.
     While doing so, pay attention that the implementation of mktime, strftime,
     strptime, etc. can be compiled with a 32-bit time_t or a 64-bit time_t.

  2) gnulib modifies its year2038 module to define _TIME_BITS to 64 at configure
     time, on platforms where glibc supports it.

  3) During the next source-code sync from glibc to gnulib, involving mktime.c
     etc., the gnulib people (likely Paul) make sure that this source code can
     still be used on non-glibc platforms with either 32-bit time_t or 64-bit
     time_t. Usually this involves a couple of #ifs and conditional #includes.
     These changes can then flow back into glibc. They won't have a functional
     effect in glibc, therefore won't break the atomicity of step 1.

AFAICS, steps 3 could also be executed before step 2.

Bruno


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