Re: time_t in gnulib

[Bruno Haible <bruno at clisp dot org>]

Hi,

> I have had a look at gnulib in the meantime, and 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.

Yes and no.

Yes, gnulib contains a year2038 module [1][2].
No, it does not "check" something: It attempts to ensure that time_t is a
64-bit type, by defining certain preprocessor symbols.
No, it does not guarantee a configuration error or compilation error if
time_t is only 32-bit. It produces a configuration error ONLY if time_t
is only 32-bit AND this can be avoided by choosing a different ABI.

> - gnulib does not contain any module which provides the time_t type, but
>   some of gnulib's modules assume there is such a type, and it might be
>   wider than 32 bits.

Correct. All portability targets of gnulib do have a time_t type. Since
it is not possible to support a wider time_t type without kernel support,
gnulib does not attempt to redefine time_t type via typedef or #define.

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

difftime is only the least problem. The bigger ones are gettimeofday,
stat, fstat. But if on some platform, difftime is the only missing piece
for supporting 64-bit time_t, gnulib could easily provide a replacement.

> - gnulib makes no assumption on how it is used in object form; notably,
>   it 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.

Correct. Gnulib provides an "application source interface" only, not an
"application binary interface".

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/Avoiding-the-year-2038-problem.html
[2] https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=m4/year2038.m4