From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121407 invoked by alias); 19 Aug 2016 21:16:06 -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 121381 invoked by uid 89); 19 Aug 2016 21:16:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=existence, inclination X-HELO: mail-yb0-f175.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=FGBkND4iSpfYmldssSFM70S1IZvpTh5/TZQ18/vL/2M=; b=kdjrl93OdMAV+WgQWtmjK3w8BbpIiS7yHCxSIXEX9MA3Csl1paocC4UycjgCslIPZU Ydwod50zgp/zCp9Wa9MYQ98XTklhlbUW+S3lruvtt4V3NArujrF8uLypWBPbXlJFqu4O xu91iT6rSqrMDfihwwIL8fDSWSCMhXRnvZ90kkO3+nDtSXV7orIGMF5nmR6x4EJ0M1cb SvyDJ2IIB8IHSYYAzyQYK+211cuq8loG88bdQSujNewzlpe9lsME9YvlRmh1rmE/IeII cOE383HzgYOgB76YYUsh3Li3kiSAfV1ckiJsFZJbn6pvUoUhTKOe1FsxbJon9JIVmGHl LLEA== X-Gm-Message-State: AEkoouv7sAZ7t9e5x4+eHYxlOo7VnzU84VzNuxyobYrAQY/f2VQlg8FbpCDDhSp5bMkvSr/L X-Received: by 10.37.70.139 with SMTP id t133mr7782467yba.179.1471641352530; Fri, 19 Aug 2016 14:15:52 -0700 (PDT) Subject: Re: [PATCH 2/4] New string function explicit_bzero (from OpenBSD). To: Zack Weinberg References: <9d17da53214c24a908092519d98bb93f4e6429f1.1471452664.git.zackw@panix.com> <5b4e1772-d28d-4845-b998-d63a91745abc@redhat.com> <1471553620.14544.109.camel@localhost.localdomain> <667c91c6-57e2-580e-1abf-e3db93a0e62b@linaro.org> <71aadb7b-604a-2ed6-e785-4a5476bb057c@panix.com> <165dcff6-55bd-f63c-39e3-ad175440068f@linaro.org> Cc: GNU C Library From: Adhemerval Zanella Message-ID: <32e4e9f5-7956-d8c7-c2ca-9e35bf7e9400@linaro.org> Date: Fri, 19 Aug 2016 21:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-08/txt/msg00670.txt.bz2 On 19/08/2016 16:54, Zack Weinberg wrote: > On Fri, Aug 19, 2016 at 12:31 PM, Adhemerval Zanella > wrote: >> Well, current memset_chk default implementation just does: >> >> if (__glibc_unlikely (dstlen < len)) >> __chk_fail (); >> >> So it would be feasible imho to just this add and call memset instead >> of memset_chk. > > For clarity, you are imagining this as the in-libc, out-of-line > implementation of __explicit_bzero_chk? Because as long as there's > *some* inline definition of explicit_bzero, we have to have the > exported __glibc_read_memory and then I don't see why we shouldn't > have a string2.h non-fortified inline as well. What I would like is, based on recent string inline headers cleanup, is to avoid adding more implementation that in the future the compiler can and would handle this transparently. Ideally it would be better if we just aims to clean all the optimization done in string2/string3 headers (as we did for recent strspn, strbrk, etc. optimizations). For this special case, I would advise go for the simple case: add a explicit_bzero and __explicit_bzero_chk in-libc as the other implementations. However I do not have a strong opinion here. > >> The problem, as pointed out by Florian, is not the symbol being exported >> itself, but the inline definition where all the 'inline' definition might >> either not being supported by the target compiler or have non-expected >> side effects (as for C++ with -O0). > > Did you miss that there *is* an out-of-line non-fortified > explicit_bzero? Which means that the bug you pointed out should be a > non-issue. The problem is not the existence of a out-of-line explicit_bzero, but if __extern_inline would use or not the gnu_inline attribute. With current guards for inclusion of string2.h (OPTIMIZE and !__cplusplus) the only case of a possible issue I can think of is if someone building with GCC lower than 4.2 with an optimized build and -fno-inline (this will define __extern_inline to just extern __inline and possible create multiple definitions). My inclination is this should not be a blocker though.