From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23469 invoked by alias); 13 Jun 2018 10:21:02 -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 23453 invoked by uid 89); 13 Jun 2018 10:21:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy= X-HELO: smtp4-g21.free.fr Date: Wed, 13 Jun 2018 10:21:00 -0000 From: Albert ARIBAUD To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 2/2] Y2038: make __tz_convert compatible with 64-bit-time Message-ID: <20180613122050.511c16e1@athena> In-Reply-To: <290446d5-cbe0-c49d-85bf-3416118786d5@redhat.com> References: <20180613070019.4639-1-albert.aribaud@3adev.fr> <20180613070019.4639-3-albert.aribaud@3adev.fr> <900b27d1-a90a-ed3a-e298-1544968a23dd@redhat.com> <20180613113652.0940f3ff@athena> <290446d5-cbe0-c49d-85bf-3416118786d5@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00301.txt.bz2 Hi Florian, On Wed, 13 Jun 2018 11:40:04 +0200, Florian Weimer wrote : > On 06/13/2018 11:36 AM, Albert ARIBAUD wrote: > > Hi Florian, > > > > On Wed, 13 Jun 2018 11:10:09 +0200, Florian Weimer > > wrote : > > > >> On 06/13/2018 09:00 AM, Albert ARIBAUD (3ADEV) wrote: > [...] > >> > >> Functions in the private namespace should be exported as GLIBC_PRIVATE. > >> Except __gmtime64_r, these functions have unwanted side effects and > >> cannot really be called from other parts of glibc anyway. > > > > They're going to be implementations of APIs called from user source code > > if/when it defines _TIME_BITS equal to 64 (that'll be the last patch in > > the whole series), so I don't understand how they could be considered > > GLIBC_PRIVATE. > > Why do they use the __ prefix? We generally do not do that. I believe it stemmed from the fact that source code should not spell these functions by their explicit name -- that name is to be used by glibc only. User source code should keep using the historical names (here, "gmtime_r"); if it has defined _TIME_BITS equal to 64, then the glibc public headers will alias (or barring that, #define) gmtime_r to __gmtime64_r (the 64-bit-time implementation); otherwise, "gmtime_r" will be used as-is (the 32-bit-time implementation). So to make sure the symbols were considered to not be for (direct) public use, they have to start with an underscore. > > As for the side effects, which ones are you thinking of? The ones I am > > aware of are those already present in the 32-bit-time versions and are > > "regrettable but established behavior". > > The side effects simply mean that we cannot call this functions as an > internal implementation detail of another function, so there should be > no reason for an export in the private namespace (with the __prefix and > GLIBC_PRIVATE). Actually another function can call these functions -- the 32-bit-time wrappers do that exactly. I must be missing your point. > Thanks, > Florian Cordialement, Albert ARIBAUD 3ADEV