From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101024 invoked by alias); 16 Jun 2018 14:03:05 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 101014 invoked by uid 89); 16 Jun 2018 14:03:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,URIBL_RED autolearn=no version=3.3.2 spammy=Hx-languages-length:1401, referred, H*Ad:D*ucla.edu X-HELO: smtp2-g21.free.fr Date: Sat, 16 Jun 2018 14:03:00 -0000 From: Albert ARIBAUD To: Joseph Myers Cc: Paul Eggert , Subject: Re: [PATCH v2 2/2] Y2038: make __tz_convert compatible with 64-bit-time Message-ID: <20180616160254.533870e8@athena> In-Reply-To: References: <20180614135116.8767-1-albert.aribaud@3adev.fr> <20180614135116.8767-3-albert.aribaud@3adev.fr> <20180614195149.60f6114d@athena> <29ea05e7-d4b0-876a-bf39-29ecf7bfa3da@cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00457.txt.bz2 Hi Joseph, On Thu, 14 Jun 2018 19:40:28 +0000, Joseph Myers 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