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.
