From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Carpenter Date: Wed, 09 Oct 2019 14:30:01 +0000 Subject: Re: [PATCH] string.h: Mark 34 functions with __must_check Message-Id: <20191009143000.GD13286@kadam> List-Id: References: <75f70e5e-9ece-d6d1-a2c5-2f3ad79b9ccb@web.de> <954c5d70-742f-7b0e-57ad-ea967e93be89@rasmusvillemoes.dk> <20191009135522.GA20194@kadam> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Rasmus Villemoes Cc: Markus Elfring , kernel-janitors@vger.kernel.org, Alexander Shishkin , Andrew Morton , Andy Shevchenko , Joe Perches , Kees Cook , Nick Desaulniers , Steven Rostedt , LKML On Wed, Oct 09, 2019 at 04:21:20PM +0200, Rasmus Villemoes wrote: > On 09/10/2019 15.56, Dan Carpenter wrote: > > That's because glibc strlen is annotated with __attribute_pure__ which > > means it has no side effects. > > I know, except it has nothing to do with glibc headers. Just try the > same thing in the kernel. gcc itself knows this about __builtin_strlen() > etc. If anything, we could annotate some of our non-standard functions > (say, memchr_inv) with __pure - then we'd both get the Wunused-value in > the nonsense cases, and allow gcc to optimize or reorder the calls. Huh. You're right. GCC already knows. So this patch is pointless like you say. regards, dan carpenter From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48CA3C47404 for ; Wed, 9 Oct 2019 14:30:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1C236206BB for ; Wed, 9 Oct 2019 14:30:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="OOvnWUKC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731514AbfJIOay (ORCPT ); Wed, 9 Oct 2019 10:30:54 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:34858 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729865AbfJIOax (ORCPT ); Wed, 9 Oct 2019 10:30:53 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x99ET5EP091425; Wed, 9 Oct 2019 14:30:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2019-08-05; bh=xieOlnCZNdH9rUJsmmz2r6xC3pikyG8vEfffwj7nqrw=; b=OOvnWUKCQhvigjaczx/qR1uBte5t61Z/QDolYiL05qZxUCsWNHdRQKhJWREdJEd50eVy S5jenrGsYWmitNcsX/IDCRwufe6OiXJ5UQ5M2ppSpZWaa+AcSSoJTDT7DWzaNvZ92hVO uMGSXQCEW/N2FRRMCg0SbTziGa6IWx3O+KfE46GFbifC9CUGDfZt+0c7VUvcHx2pt6Gs NE04+Y6luipnF1BAt8CfIXyGgYtIyvqAw9xs4V9B/QLW/mdy86Nk8Lju35NBFPsrTu+E kiSOurdkp2EDfP9qCSs9784af8DYrJeekHVKz5Tay4qF9HKcwM/8yngIl6RdKmbPI7a4 Nw== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 2vektrmsct-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 09 Oct 2019 14:30:15 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x99ENELC032173; Wed, 9 Oct 2019 14:30:15 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2vgev1gx1s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 09 Oct 2019 14:30:15 +0000 Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x99EUAlf020123; Wed, 9 Oct 2019 14:30:12 GMT Received: from kadam (/41.57.98.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Oct 2019 07:30:10 -0700 Date: Wed, 9 Oct 2019 17:30:01 +0300 From: Dan Carpenter To: Rasmus Villemoes Cc: Markus Elfring , kernel-janitors@vger.kernel.org, Alexander Shishkin , Andrew Morton , Andy Shevchenko , Joe Perches , Kees Cook , Nick Desaulniers , Steven Rostedt , LKML Subject: Re: [PATCH] string.h: Mark 34 functions with __must_check Message-ID: <20191009143000.GD13286@kadam> References: <75f70e5e-9ece-d6d1-a2c5-2f3ad79b9ccb@web.de> <954c5d70-742f-7b0e-57ad-ea967e93be89@rasmusvillemoes.dk> <20191009135522.GA20194@kadam> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9404 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=814 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910090139 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9404 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=894 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910090140 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 09, 2019 at 04:21:20PM +0200, Rasmus Villemoes wrote: > On 09/10/2019 15.56, Dan Carpenter wrote: > > That's because glibc strlen is annotated with __attribute_pure__ which > > means it has no side effects. > > I know, except it has nothing to do with glibc headers. Just try the > same thing in the kernel. gcc itself knows this about __builtin_strlen() > etc. If anything, we could annotate some of our non-standard functions > (say, memchr_inv) with __pure - then we'd both get the Wunused-value in > the nonsense cases, and allow gcc to optimize or reorder the calls. Huh. You're right. GCC already knows. So this patch is pointless like you say. regards, dan carpenter