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

[Paul Eggert <eggert@cs.ucla.edu>]

On 06/14/2018 10:51 AM, Albert ARIBAUD wrote:
> The asymmetry (that ctime and ctime_r are only declared in time/time.h
> whereas localtime, localtime_r, gmtime and gmtime_r are declared both in
> include/time.h as well as time/time.h) existed before my patches, and I
> do not know the reason.

I suspect it's because time/time.h is intended to be public (copied to 
/usr/include/time.h) whereas include/time.h is merely private to glibc. 
Since ctime and ctime_r are not useful internally (they are 
specializations of strftime that are standardized only because of 
inertia: 7th Edition Unix had ctime but not strftime), there is no need 
for private declarations of ctime and ctime_r in include/time.h because 
glibc code never calls these functions.

Given all that, why bother defining __ctime64 and __ctime64_r in 
include/time.h? glibc code never calls these functions so these #defines 
can be localized to time/ctime.c and time/ctime_r.c respectively, with a 
comment explaining why the #defines are local.

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?