[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/1] Y2038: add function __difftime64

From: Bruno Haible
Subject: Re: [PATCH 1/1] Y2038: add function __difftime64
Date: Thu, 05 Jul 2018 23:17:26 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-128-generic; KDE/5.18.0; x86_64; ; )

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]