From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39575 invoked by alias); 16 Nov 2016 14:45:26 -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 39511 invoked by uid 89); 16 Nov 2016 14:45:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=HTo:U*rth, discussing, __socket, __getrlimit X-HELO: mail-qk0-f193.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qsU/E3jt/JEyOiUkn6WmyV1hvKriDR4bYf+gKyRNarI=; b=YLQMnq32DrADvQJwkZnpOHov1U/jgWK2tXPFcNz48ovEZ1dR2X+rKkOsZzKQ1cYo8O FYwa/z+SdNP3FA1n2pieHYHkbzuf1/yyQrtlWuB29kkufdMtY44MwwooN1tWh9Ubyaeu NNll1n1masX1KO+DLKme8WtinN+6bM66TVOVe0H2WRsBpfN5r6Chcv+gRtGDRRfE7oYH cqeL5gLV8cWY8JXdh1mVCby88dRTq26yNmXGWUulo+gV2NTwXjhx36kteCmcCeyfIu2V W12zf4fbyiOti52p9Zkbf/OSzR3GtQrtsIn5V0XZJ+Ei72i7t4/lcdZpLOTYw74mN6dV +pag== X-Gm-Message-State: AKaTC00sWHZLpT/UtZUkgEtBlHb5W+Lz/CziUUqA462kQzcJN3TRpVY2RVB2rFeExY26+Q== X-Received: by 10.55.134.66 with SMTP id i63mr3472915qkd.309.1479307519754; Wed, 16 Nov 2016 06:45:19 -0800 (PST) Subject: Re: [PATCH 0/3] explicit_bzero v5 To: Richard Henderson , libc-alpha@sourceware.org References: <20161115155509.12692-1-zackw@panix.com> Cc: fweimer@redhat.com From: Zack Weinberg Message-ID: <500cef03-f7e2-f152-660d-438b08ac1f45@panix.com> Date: Wed, 16 Nov 2016 14:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-11/txt/msg00553.txt.bz2 On 11/15/2016 04:11 PM, Richard Henderson wrote: > On 11/15/2016 04:55 PM, Zack Weinberg wrote: >> I wasn't able to find anything definitive about when GLIBC_PRIVATE >> should be used. > > Between .so libraries of glibc's implementation, as such symbols are > (wait for it) private and are allowed to change at will between releases. This doesn't fully resolve the question in my head, though. The case we're discussing is an impl-namespace symbol __explicit_bzero, which is functionally identical to a public symbol explicit_bzero, and not expected ever to change its behavior. It exists, as far as I understand, _solely_ so that uses of this symbol in libcrypt.so will resolve to the definition in libc.so even if other objects in the link interpose on the public symbol. Other symbols that exist for the same reason have been given both GLIBC_2.xx versions (e.g. __bzero, __strtok_r, __clone, __connect, __send) and GLIBC_PRIVATE versions (__getrlimit, __madvise, __recv, __socket) so I don't know what is considered to be the Right Thing. (If I were to make the public declaration in string.h redirect to __explicit_bzero, then clearly it ought to be a GLIBC_2.xx export rather than a GLIBC_PRIVATE export. But, as I'll go into more elsewhere, I'm not convinced that's actually a good idea.) zw