From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95099 invoked by alias); 13 Jun 2018 13:08:44 -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 95084 invoked by uid 89); 13 Jun 2018 13:08:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Subject: Re: [PATCH 2/2] Y2038: make __tz_convert compatible with 64-bit-time To: Albert ARIBAUD Cc: libc-alpha@sourceware.org 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> <20180613122050.511c16e1@athena> From: Florian Weimer Message-ID: <9ff2582c-f53f-414c-d638-444c8c7c7792@redhat.com> Date: Wed, 13 Jun 2018 13:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180613122050.511c16e1@athena> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00308.txt.bz2 On 06/13/2018 12:20 PM, Albert ARIBAUD wrote: > 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. We use non-__ names for the LFS redirects (slightly trimmed): # ifdef __REDIRECT extern FILE *__REDIRECT (fopen, (const char *__restrict, const char *__restrict), fopen64); extern FILE *__REDIRECT (freopen, (const char *__restrict, const char *__restrict, FILE *__restrict), freopen64); # else # define fopen fopen64 # define freopen freopen64 # endif #endif I don't see a totally conforming way to implement this using redirects anyway, so whether __ is used or not is secondary because it doesn't address the main problem. >>> 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. Yes, but that those are libc-only and they won't need the exports. A hidden alias with a __ name would be sufficient under such circumstances. Thanks, Florian