[PATCH 1/1] Y2038: add function __difftime64

[Paul Eggert]

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).