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: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: bug-gnulib at gnu dot org, libc-alpha at sourceware dot org
- Date: Thu, 5 Jul 2018 22:38:01 +0200
- 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>
Hi Paul,
On Thu, 5 Jul 2018 12:40:07 -0700, Paul Eggert <eggert@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