From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83721 invoked by alias); 13 Jun 2018 09:40:09 -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 83707 invoked by uid 89); 13 Jun 2018 09:40:08 -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=unwanted, Theyre, They're 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> From: Florian Weimer Message-ID: <290446d5-cbe0-c49d-85bf-3416118786d5@redhat.com> Date: Wed, 13 Jun 2018 09:40: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: <20180613113652.0940f3ff@athena> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00299.txt.bz2 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: >>> + GLIBC_2.28 { >>> + __ctime64; __ctime64_r; >>> + __gmtime64; __gmtime64_r; >>> + __localtime64; __localtime64_r; >>> + } >> >> 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. > 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). Thanks, Florian