This is the mail archive of the
libc-alpha@sourceware.org
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: bug-gnulib at gnu dot org, libc-alpha at sourceware dot org
- Date: Fri, 6 Jul 2018 15:37:38 -0700
- Subject: Re: [PATCH 1/1] Y2038: add function __difftime64
- References: <20180620121427.25397-1-albert.aribaud@3adev.fr> <20180620121427.25397-2-albert.aribaud@3adev.fr> <9b02ad78-15cf-969e-b2ef-cae13d5a689e@cs.ucla.edu> <20180620225545.4eb76291@athena> <31f71b4a-6141-f27a-3385-3653f58adb28@cs.ucla.edu> <20180626003245.023eb716@athena> <6c6c0111-572d-538a-e9e7-26b43b44d6c4@cs.ucla.edu> <20180627130342.41cc6992@athena> <20180705203637.66ae4947@athena> <90246a4c-86cc-c191-8564-e6eea556fa13@cs.ucla.edu> <20180705223801.6e19c637@athena>
Albert ARIBAUD wrote:
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 is easier to change than glibc, so it makes sense to update it first.
Currently Gnulib's year2038 module doesn't enable any Glibc macros to prefer 64-
to 32-bit time_t when both are available - since there aren't any - but when
Glibc has one, we will change Gnulib to define the macro. We can make this
change to Gnulib now, if the Glibc macro's name is stable (is it?). However, I
was thinking of something more ambitious: having Gnulib support 64-bit time_t on
32-bit glibc now, even before the Glibc support is in. In doing this, it would
emulate the planned Glibc behavior by defining the Glibc macro's name (even
though the underlying Glibc doesn't use the macro yet). As this is still a
possibility, I would rather not make the assumption that Gnulib will never
contain such a change.
That is partly why I don't want to hand-optimize difftime for the specific case
of 64-bit time_t. We should continue to have a generic difftime that will work
regardless of time_t width, as we may need it in Gnulib (even if we don't need
it in this go-round).
(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).
As I said, doing all that is not something I recommend.
The goal here is not merely making glibc Y2038-proof; it is also keeping it
glibc in sync with Gnulib when possible, while keeping Gnulib portable (which
also includes keeping Gnulib Y2038-proof, on platforms with time_t that can go
past Y2038).