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
