Message ID | 20201104090547.1376086-1-siddhesh@sourceware.org |
---|---|
State | Superseded |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F01D338708CE; Wed, 4 Nov 2020 09:06:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F01D338708CE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1604480797; bh=LF/q3DcLyxzuE3vKHTm4XXF7aAhWfZK0u5IdpCsMD60=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=q0iEoegmQkRTFQI/H8M5n3Sm8N0iierJA8HkMbd8i+FI0ogNBhEE1uS9ufN0ERmp9 fLrOPDqhN9lToE+ZRNyMgvojRwKm5+ZT/Gt3cBcJCv/kdYonkrMYlLHJjL/3LqPtrL TxgjHCHDkQAv+wojC0cKanmdDW2EAggaNa+ITTws= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from dragonfly.birch.relay.mailchannels.net (dragonfly.birch.relay.mailchannels.net [23.83.209.51]) by sourceware.org (Postfix) with ESMTPS id 72D30386103A for <libc-alpha@sourceware.org>; Wed, 4 Nov 2020 09:06:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 72D30386103A X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id CBBC018062A; Wed, 4 Nov 2020 09:06:30 +0000 (UTC) Received: from pdx1-sub0-mail-a72.g.dreamhost.com (100-98-118-43.trex.outbound.svc.cluster.local [100.98.118.43]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D73C3181BC6; Wed, 4 Nov 2020 09:06:29 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a72.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.10); Wed, 04 Nov 2020 09:06:30 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Soft-Tasty: 0e1ede29014987ae_1604480790121_1757102058 X-MC-Loop-Signature: 1604480790121:2586259290 X-MC-Ingress-Time: 1604480790121 Received: from pdx1-sub0-mail-a72.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a72.g.dreamhost.com (Postfix) with ESMTP id 958A17EBF1; Wed, 4 Nov 2020 01:06:29 -0800 (PST) Received: from rhbox.redhat.com (unknown [123.252.202.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 2828A7E394; Wed, 4 Nov 2020 01:06:26 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a72 To: libc-alpha@sourceware.org Subject: [PATCH] Remove __warn_memset_zero_len [bz #25399] Date: Wed, 4 Nov 2020 14:35:47 +0530 Message-Id: <20201104090547.1376086-1-siddhesh@sourceware.org> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Siddhesh Poyarekar via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Siddhesh Poyarekar <siddhesh@sourceware.org> Cc: fweimer@redhat.com, jakub@redhat.com, sguelton@redhat.com Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
Remove __warn_memset_zero_len [bz #25399]
|
|
Commit Message
Siddhesh Poyarekar
Nov. 4, 2020, 9:05 a.m. UTC
Non-gcc compilers (clang and possibly other compilers that do not masquerade as gcc 5.0 or later) are unable to use __warn_memset_zero_len since the symbol is no longer available on glibc built with gcc 5.0 or later. While it was likely an oversight that caused this omission, the fact that it wasn't noticed until recently (when clang closed the gap on _FORTIFY_SUPPORT) that the symbol was missing. Given that both gcc and clang are capable of doing this check in the compiler, drop all signs of __warn_memset_zero_len from glibc. The __warndecl macro remains in there unused in the event that we need it to add a similar check in future. --- string/bits/string_fortified.h | 15 --------------- 1 file changed, 15 deletions(-)
Comments
* Siddhesh Poyarekar: > Non-gcc compilers (clang and possibly other compilers that do not > masquerade as gcc 5.0 or later) are unable to use > __warn_memset_zero_len since the symbol is no longer available on > glibc built with gcc 5.0 or later. While it was likely an oversight > that caused this omission, the fact that it wasn't noticed until > recently (when clang closed the gap on _FORTIFY_SUPPORT) that the > symbol was missing. > > Given that both gcc and clang are capable of doing this check in the > compiler, drop all signs of __warn_memset_zero_len from glibc. > > The __warndecl macro remains in there unused in the event that we need > it to add a similar check in future. Nit: We tend to write: [BZ #25399] (But the Git update hook does not react to the commit subject these days.) Patch looks good. Please remove the last paragraph of the commit message and send a separate patch to remove __warndecl. 8-) Thanks, FLorian
On Wed, Nov 04, 2020 at 10:19:25AM +0100, Florian Weimer wrote: > * Siddhesh Poyarekar: > > > Non-gcc compilers (clang and possibly other compilers that do not > > masquerade as gcc 5.0 or later) are unable to use > > __warn_memset_zero_len since the symbol is no longer available on > > glibc built with gcc 5.0 or later. While it was likely an oversight > > that caused this omission, the fact that it wasn't noticed until > > recently (when clang closed the gap on _FORTIFY_SUPPORT) that the > > symbol was missing. > > > > Given that both gcc and clang are capable of doing this check in the > > compiler, drop all signs of __warn_memset_zero_len from glibc. > > > > The __warndecl macro remains in there unused in the event that we need > > it to add a similar check in future. > > Nit: We tend to write: [BZ #25399] > (But the Git update hook does not react to the commit subject these days.) > > Patch looks good. Please remove the last paragraph of the commit > message and send a separate patch to remove __warndecl. 8-) I think it can't be really removed. It is ok if it doesn't warn anymore, and it is ok if it is not in the headers anymore, but one can still have object files or *.a libraries compiled with gcc 4.9 and earlier against older glibc and that will now fail to link altogether. Jakub
* Jakub Jelinek: > It is ok if it doesn't warn anymore, and it is ok if it is not in the > headers anymore, but one can still have object files or *.a libraries > compiled with gcc 4.9 and earlier against older glibc and that will > now fail to link altogether. In general, that is not supported. We have recently made an exception for __xstat. But in this case, linking after removal will only fail if there was an annoying linker warning before, so I think it's going to be very rare that this makes a difference. Thanks, Florian
On 11/4/20 3:10 PM, Florian Weimer via Libc-alpha wrote: > * Jakub Jelinek: > >> It is ok if it doesn't warn anymore, and it is ok if it is not in the >> headers anymore, but one can still have object files or *.a libraries >> compiled with gcc 4.9 and earlier against older glibc and that will >> now fail to link altogether. > > In general, that is not supported. We have recently made an exception > for __xstat. But in this case, linking after removal will only fail if > there was an annoying linker warning before, so I think it's going to be > very rare that this makes a difference. I suppose another way to look at this is that the patch does not fix the link failure, it only ensures that the symbol doesn't appear in the future by accident. We can then look at fixing the link failure by adding the symbol in if someone actually cares enough to file another bug. Does that sound reasonable? Siddhesh
* Siddhesh Poyarekar: > On 11/4/20 3:10 PM, Florian Weimer via Libc-alpha wrote: >> * Jakub Jelinek: >> >>> It is ok if it doesn't warn anymore, and it is ok if it is not in the >>> headers anymore, but one can still have object files or *.a libraries >>> compiled with gcc 4.9 and earlier against older glibc and that will >>> now fail to link altogether. >> In general, that is not supported. We have recently made an >> exception >> for __xstat. But in this case, linking after removal will only fail if >> there was an annoying linker warning before, so I think it's going to be >> very rare that this makes a difference. > > I suppose another way to look at this is that the patch does not fix > the link failure, it only ensures that the symbol doesn't appear in > the future by accident. > > We can then look at fixing the link failure by adding the symbol in if > someone actually cares enough to file another bug. Does that sound > reasonable? Eh, right. The __warn_memset_zero_len symbol is currently not part of libc_nonshared.a. (Our downstream build of 2.17 still has it, but the one based on 2.28 does not, due to a different GCC version being used.) So there is no new backwards compatibility impact from remove the __warndecl stuff. Thanks, Florian
On 11/4/20 3:26 PM, Florian Weimer via Libc-alpha wrote: > Eh, right. The __warn_memset_zero_len symbol is currently not part of > libc_nonshared.a. (Our downstream build of 2.17 still has it, but the > one based on 2.28 does not, due to a different GCC version being used.) > So there is no new backwards compatibility impact from remove the > __warndecl stuff. I have pushed this now. Siddhesh
diff --git a/string/bits/string_fortified.h b/string/bits/string_fortified.h index 309d0f39b2..c8d3051af8 100644 --- a/string/bits/string_fortified.h +++ b/string/bits/string_fortified.h @@ -22,11 +22,6 @@ # error "Never use <bits/string_fortified.h> directly; include <string.h> instead." #endif -#if !__GNUC_PREREQ (5,0) -__warndecl (__warn_memset_zero_len, - "memset used with constant zero length parameter; this could be due to transposed parameters"); -#endif - __fortify_function void * __NTH (memcpy (void *__restrict __dest, const void *__restrict __src, size_t __len)) @@ -58,16 +53,6 @@ __NTH (mempcpy (void *__restrict __dest, const void *__restrict __src, __fortify_function void * __NTH (memset (void *__dest, int __ch, size_t __len)) { - /* GCC-5.0 and newer implements these checks in the compiler, so we don't - need them here. */ -#if !__GNUC_PREREQ (5,0) - if (__builtin_constant_p (__len) && __len == 0 - && (!__builtin_constant_p (__ch) || __ch != 0)) - { - __warn_memset_zero_len (); - return __dest; - } -#endif return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); }