|
From: | Paul Eggert |
Subject: | Re: [PATCH 1/1] Y2038: add function __difftime64 |
Date: | Thu, 5 Jul 2018 12:40:07 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |