[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: Wed, 01 Aug 2018 15:25:59 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-130-generic; KDE/5.18.0; x86_64; ; )

Hello Albert,

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


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


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


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

Incorrect. I explained this in

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


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


reply via email to

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