This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 1/1] Y2038: add function __difftime64
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Cc: libc-alpha at sourceware dot org, bug-gnulib at gnu dot org
- Date: Thu, 5 Jul 2018 12:40:07 -0700
- Subject: Re: [PATCH 1/1] Y2038: add function __difftime64
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <20180620225545.4eb76291@athena> <firstname.lastname@example.org> <20180626003245.023eb716@athena> <email@example.com> <20180627130342.41cc6992@athena> <20180705203637.66ae4947@athena>
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 ... makes no assumption that it will be compiled into a shared object
form which will provide the same functionalities for both 64-bit and
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.