Re: [PATCH v2 2/2] Y2038: make __tz_convert compatible with 64-bit-time

[Albert ARIBAUD <albert.aribaud@3adev.fr>]

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