Hi Paul, On Thu, 5 Jul 2018 12:40:07 -0700, Paul Eggert <egg...@cs.ucla.edu> wrote :
> 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. Now I'm confused. I was under the impression that you wanted the 64-bit-time stuff to go in gnulib before it went in glibc, so I don't get what the "once glibc has such a macro" means. Can you elaborate on what you had in mind? > > - 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. Ditto. > > - 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. OK, so taking mktime as an example since gnulib provides it, and assuming a platform where time_t is not currently Y2038-proof, if I wanted to have a Y2038-proof mktime implementation in addition to the existing non-Y2038-proof one, I could compile mktime.c twice, once with the native non-Y2038-proof time_t and one with a redefined Y2038-proof time_t and with mktime #defined to another name to avoid having the mktime symbol defined twice. (but I don't see yet how this is going to help making glibc Y2038-proof. As far as I understand, glibc does not use gnulib and I don't think its build system ever compiles a single C source file into two object files for two different word sizes anyway). Cordialement, Albert ARIBAUD 3ADEV
