From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23945 invoked by alias); 28 Oct 2016 13:32: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 23860 invoked by uid 89); 28 Oct 2016 13:32:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:10.0.0, HX-HELO:sk:mail-vk X-HELO: mail-vk0-f43.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:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=8rTSRAQrg8yMAVQQmxwtmktNv7S1zgWsdtLIoQAFEm8=; b=ETusLi+sIZsMXLkgIdDZ5vNR4QJYbxKHAXJqlCQKfPZUNi59ooCLBqGhN5O535JBIP s2KK5tl8I85IHAlw9xQJEEBk2M7I9cs3+TQTjLLLVgdGDUOzLQpNCJ2SEPPMDp21uYp8 W/1Z4g38JHNECcgANEETa8mA948tMXXU18oVaJAOcH6Nqj1zwBHNyPkbPw+Z18pExR+2 kRdxMFHyL2a7uRqpNZqpeXmNTo8nYCXkJW/JCg2vGu0oWhfFy+CQYo1psmcJ8Gsudh+7 S7wy3En5lDc0By0ic/iiltywy2lVnh4/UsviLu0oxrxevT2aH/7ITJtUolSXclYWMXqU 6GHg== X-Gm-Message-State: ABUngvfs1eHlGugr38rV2QdfmyY3u4g+GOxBLjlY8fufHsNJ7rNW+TNz2uvIBGtvQ+p5oT3/ X-Received: by 10.31.63.12 with SMTP id m12mr10847836vka.33.1477661509820; Fri, 28 Oct 2016 06:31:49 -0700 (PDT) Subject: Re: [PATCH] crypt: Use internal names for the SHA-2 block functions To: libc-alpha@sourceware.org References: From: Adhemerval Zanella Message-ID: Date: Fri, 28 Oct 2016 13:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-10/txt/msg00534.txt.bz2 On 28/10/2016 10:57, Florian Weimer wrote: > I have not been able to test the SPARC bits so far, but they look reasonably safe to me. > --- a/sysdeps/sparc/sparc64/multiarch/sha256-block.c > +++ b/sysdeps/sparc/sparc64/multiarch/sha256-block.c > @@ -1,12 +1,12 @@ > #include > > -#define sha256_process_block sha256_process_block_generic > -extern void sha256_process_block_generic (const void *buffer, size_t len, > - struct sha256_ctx *ctx); > +#define __sha256_process_block __sha256_process_block_generic > +extern void __sha256_process_block_generic (const void *buffer, size_t len, > + struct sha256_ctx *ctx); > > #include > > -#undef sha256_process_block > +#undef __sha256_process_block > > extern void __sha256_process_block_crop (const void *buffer, size_t len, > struct sha256_ctx *ctx); > @@ -25,6 +25,8 @@ static bool cpu_supports_sha256(int hwcap) > return false; > } > > -extern void sha256_process_block (const void *buffer, size_t len, > - struct sha256_ctx *ctx); > -sparc_libc_ifunc(sha256_process_block, cpu_supports_sha256(hwcap) ? __sha256_process_block_crop : sha256_process_block_generic); > +extern void __sha256_process_block (const void *buffer, size_t len, > + struct sha256_ctx *ctx); > +sparc_libc_ifunc (__sha256_process_block, > + cpu_supports_sha256(hwcap) ? __sha256_process_block_crop > + : sha256_process_block_generic); It should __sha256_process_block_generic here. Also, if we now aiming for namespace clean shouldn't we also add a conform test for crypt.h header?