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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 904CDC77B7F for ; Wed, 3 May 2023 08:45:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229887AbjECIpC (ORCPT ); Wed, 3 May 2023 04:45:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229820AbjECIoy (ORCPT ); Wed, 3 May 2023 04:44:54 -0400 Received: from nautica.notk.org (ipv6.notk.org [IPv6:2001:41d0:1:7a93::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3EA803C29; Wed, 3 May 2023 01:44:53 -0700 (PDT) Received: by nautica.notk.org (Postfix, from userid 108) id E3E60C022; Wed, 3 May 2023 10:44:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1683103491; bh=rDa2GFnRyj0u/PaMCdh8MXpYEbFGmlro85sNxPD/eVM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ElKdUtHVBCkVeQSbl+UNy6iaV1G4VhujQF22VhlaRZKhI6A1qMjrS5JMnEX0ozFL5 oQ/8GB7uqhqj7bJmGOxZoA+ARDkOD19Gs8CA8mQULrJUknNj+RP1lNRiNhu5ANfnBk 4PytgsK0Mfk470n1LCZdhzWCdR8rvN8VgbtHFoIvGY4WYpN1xlIOJI31R6L7ZSKFAG FumSILzqCE7T/Bea0UbpgOCwMsR2IF6deW41oEnjLHiU2BGeIMR7WiVuFd85QG7POf fPYOsG5bzYFoX6l08ftQlE4W/GALROmpTr7S63Jij3ro1AtzmeLvts4KRTWyp2Nyi1 A2JhqJBDGoKAg== Received: from odin.codewreck.org (localhost [127.0.0.1]) by nautica.notk.org (Postfix) with ESMTPS id CC6A4C009; Wed, 3 May 2023 10:44:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1683103491; bh=rDa2GFnRyj0u/PaMCdh8MXpYEbFGmlro85sNxPD/eVM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ElKdUtHVBCkVeQSbl+UNy6iaV1G4VhujQF22VhlaRZKhI6A1qMjrS5JMnEX0ozFL5 oQ/8GB7uqhqj7bJmGOxZoA+ARDkOD19Gs8CA8mQULrJUknNj+RP1lNRiNhu5ANfnBk 4PytgsK0Mfk470n1LCZdhzWCdR8rvN8VgbtHFoIvGY4WYpN1xlIOJI31R6L7ZSKFAG FumSILzqCE7T/Bea0UbpgOCwMsR2IF6deW41oEnjLHiU2BGeIMR7WiVuFd85QG7POf fPYOsG5bzYFoX6l08ftQlE4W/GALROmpTr7S63Jij3ro1AtzmeLvts4KRTWyp2Nyi1 A2JhqJBDGoKAg== Received: from localhost (odin.codewreck.org [local]) by odin.codewreck.org (OpenSMTPD) with ESMTPA id ecff0b1d; Wed, 3 May 2023 08:44:44 +0000 (UTC) Date: Wed, 3 May 2023 17:44:29 +0900 From: Dominique Martinet To: Christian Schoenebeck Cc: Eric Van Hensbergen , Latchesar Ionkov , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , v9fs@lists.linux.dev, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH v2 5/5] 9p: remove dead stores (variable set again without being read) Message-ID: References: <20230427-scan-build-v2-0-bb96a6e6a33b@codewreck.org> <20230427-scan-build-v2-5-bb96a6e6a33b@codewreck.org> <3207385.lLoMtQYYpd@silver> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3207385.lLoMtQYYpd@silver> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christian Schoenebeck wrote on Wed, May 03, 2023 at 10:22:46AM +0200: > On Wednesday, May 3, 2023 9:49:29 AM CEST Dominique Martinet wrote: > > The 9p code for some reason used to initialize variables outside of the > > declaration, e.g. instead of just initializing the variable like this: > > > > int retval = 0 > > > > We would be doing this: > > > > int retval; > > retval = 0; > > OK, but AFAICS this patch would simply remove all initializations. I would > expect at least a default initialization at variable declaration instead. Yes, clang doesn't seem to complain about 'int reval = 0' so the patch can just be updated to do that instead; I just removed them because the sheer number made it faster to do that. Happy to drop this last patch for now and rework it when time permits. > > This is perfectly fine and the compiler will just optimize dead stores > > anyway, but scan-build seems to think this is a problem and there are > > many of these warnings making the output of scan-build full of such > > warnings: > > fs/9p/vfs_inode.c:916:2: warning: Value stored to 'retval' is never read [deadcode.DeadStores] > > retval = 0; > > ^ ~ > > Honestly I don't see much value in this warning. Can't we just disable this > warning for 9p code or is this just controllable for the entire project? Dead stores in itself is a useful warning, it's what found the real bug where return value was lost in patch 1 of this series, I don't think we should just disable the warning. -- Dominique Martinet | Asmadeus