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

[Bruno Haible]

Hello Albert,

> Gnulib does not provide time_t
> 
> and relies on the underlying system, which may or may not include GLIBC.

Correct.

> IIUC:
> 
>  * Gnulib does not *define* time_t at all, always assuming
>    that it will exist in the underlying system.

Correct.

>  * Also, Gnulib may, if module Y2038 is used, check whether time_t is
>    Y2038-proof or not.

Yes.

>  * If the underlying time_t is not Y2038-proof, Gnulib makes no effort
>    to fix the situation.

Incorrect. I explained this in
<https://lists.gnu.org/archive/html/bug-gnulib/2018-07/msg00041.html>.

>  * Making Gnulib Y2038-proof would require (for starters) providing a
>    Y2038-proof time type to application code.
> 
>  * This would be done by modifying the existing Y2038 module.

Yes. But it is not possible to support a wider time_t type without kernel
support, and in Gnulib we usually don't want to be in the business of
interfacing with the kernel directly - that is the business of the libc.
Therefore a Gnulib-defined time_t type is not likely to happen.

>  * Contrary to the GLIBC case, there would be no need to provide the
>    'new' type alongside an 'old' one to application code; only the 'new'
>    type would be presented.

Correct.

>  * But some Gnulib functions may need to use both the Y2038-proof time
>    type and the underlying system's time type.

This is exactly the problem. If Gnulib provides a time_t type, and since
we don't want the application code to require changes, Gnulib must also
provide wrappers or replacement for _all_ system functions that reference
a time_t type. This is a huge complexity.

I considered doing a similar thing with wchar_t on Windows platforms
(define a 32-bit wchar_t where the system one is only 16-bit), but gave
up, facing the huge complexity.

Bruno