[Top][All Lists]

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

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

From: Paul Eggert
Subject: Re: [PATCH 1/1] Y2038: add function __difftime64
Date: Fri, 6 Jul 2018 15:37:38 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

Albert ARIBAUD wrote:

Although true for now, in the long run year2038 could be changed to enable
macros that will cause the implementation to use 64- instead of 32-bit time_t.
This is a plausible thing to do once glibc has such a macro.

Now I'm confused. 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?

Gnulib is easier to change than glibc, so it makes sense to update it first.

Currently Gnulib's year2038 module doesn't enable any Glibc macros to prefer 64- to 32-bit time_t when both are available - since there aren't any - but when Glibc has one, we will change Gnulib to define the macro. We can make this change to Gnulib now, if the Glibc macro's name is stable (is it?). However, I was thinking of something more ambitious: having Gnulib support 64-bit time_t on 32-bit glibc now, even before the Glibc support is in. In doing this, it would emulate the planned Glibc behavior by defining the Glibc macro's name (even though the underlying Glibc doesn't use the macro yet). As this is still a possibility, I would rather not make the assumption that Gnulib will never contain such a change.

That is partly why I don't want to hand-optimize difftime for the specific case of 64-bit time_t. We should continue to have a generic difftime that will work regardless of time_t width, as we may need it in Gnulib (even if we don't need it in this go-round).

(but I don't see yet how this is going to help making glibc Y2038-proof.
As far as I understand, glibc does not use gnulib and I don't think its
build system ever compiles a single C source file into two object files
for two different word sizes anyway).

As I said, doing all that is not something I recommend.

The goal here is not merely making glibc Y2038-proof; it is also keeping it glibc in sync with Gnulib when possible, while keeping Gnulib portable (which also includes keeping Gnulib Y2038-proof, on platforms with time_t that can go past Y2038).

reply via email to

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