This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 2/2] Y2038: make __tz_convert compatible with 64-bit-time
Hi Joseph,
On Thu, 14 Jun 2018 19:40:28 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :
> On Thu, 14 Jun 2018, Paul Eggert wrote:
>
> > Also, isn't glibc a bit busted in this area? ctime_r is not part of standard
> > C, so why isn't ctime_r treated like asctime_r, with a weak alias? Isn't this
> > a (separate) bug that needs to be fixed, so that the resulting weak alias is
> > like the one for localtime_r as far as 64-bit times is concerned?
>
> localtime_r is defined in the same file as localtime, so needs to be weak.
> ctime_r is not defined in the same file as ctime, and is not referenced by
> the implementations of any standard C functions, so does not need to be
> weak. (If it were referenced by a standard C function, the reference
> would have to be to __ctime_r and ctime_r would have to be a weak alias of
> that.)
>
Well, I can tell that if I remove the __ctime64 and __ctime64_r defines
and then build glibc for x86_64-linux-gnu, the linker stage fails due to
nis/nis_print.c lines 336 and 338 referring to an undefined ctime().
(OTOH, ctime_r is not referred to at all in glibc)
So at least I need to keep the '#define __ctime64 ctime' line -- I will
add a comment above it indicating that nis/nos_print.c needs it, and I
will remove the __ctime64_r define.
Cordialement,
Albert ARIBAUD
3ADEV