From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116507 invoked by alias); 18 Jun 2018 13:34:45 -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 116473 invoked by uid 89); 18 Jun 2018 13:34:44 -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=compliance, awkward, formal, ongoing X-HELO: mx1.redhat.com Subject: Re: [PATCH 2/2] Y2038: make __tz_convert compatible with 64-bit-time To: Joseph Myers Cc: Albert ARIBAUD , 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> From: Florian Weimer Message-ID: <76091890-f279-e399-3124-97c663e64a41@redhat.com> Date: Mon, 18 Jun 2018 13:34: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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00485.txt.bz2 On 06/13/2018 04:24 PM, Joseph Myers wrote: > On Wed, 13 Jun 2018, Florian Weimer wrote: > >>> 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. > > Because we want to fix bug 14106, and not replicate it for new interfaces > (and don't intend to have explicit *64 APIs at all for 64-bit time_t, just > new ABIs, on platforms where time_t is currently 32-bit, which can be > selected using _TIME_BITS=64). Ohh, right. On the other hand, it is quite awkward why these obscure interfaces receive protection from accidental interposition, when others where we know that there is ongoing interposition (fadd, fdiv, canonicalize, explicit_bzero, getrandom, even getline) do not. This relates to an older thread: It also affects _GNU_SOURCE avoidance for libstdc++, depending on how we view this. (Formal compliance vs avoiding collisions which occur in practice.) Thanks, Florian