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

[Paul Eggert]

Albert ARIBAUD wrote:
> I would like to know
> if the following assumptions are correct:
>
> - gnulib contains a year2038 module which is only intended to check
>    whether time_t is limited to Y2038 or not.

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.

> - gnulib does not provide difftime either, so ATM a difftime patch
>    would only make sense in glibc, not gnulib.

Although Gnulib hasn't needed a difftime module yet, it might need one once this 
32- vs 64-bit time_t stuff lands into glibc, so let's keep difftime.c usable for 
Gnulib.

> - gnulib ... makes no assumption that it will be compiled into a shared object
>    form which will provide the same functionalities for both 64-bit and
>    32-bit callers.

Although that's generally true, Gnulib can be used in such shared objects by 
compiling it twice (once for each model), using different names for each entry 
point. I vaguely recall some people doing this sort of thing for 32- vs 64-bit 
file offsets, though I don't recommend the practice myself.