This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/1] Y2038: add function __difftime64
- From: Bruno Haible <bruno at clisp dot org>
- To: bug-gnulib at gnu dot org
- Cc: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, Paul Eggert <eggert at cs dot ucla dot edu>, libc-alpha at sourceware dot org
- Date: Thu, 05 Jul 2018 23:17:26 +0200
- Subject: Re: [PATCH 1/1] Y2038: add function __difftime64
- References: <20180620121427.25397-1-albert.aribaud@3adev.fr> <90246a4c-86cc-c191-8564-e6eea556fa13@cs.ucla.edu> <20180705223801.6e19c637@athena>
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