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
