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 shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B59A1C433EF for ; Fri, 22 Apr 2022 15:21:40 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94.2) (envelope-from ) id 1nhuqJ-0004tC-JD; Fri, 22 Apr 2022 11:05:07 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nhul7-00046b-HQ for kernelnewbies@kernelnewbies.org; Fri, 22 Apr 2022 10:59:45 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id E837C320399D; Fri, 22 Apr 2022 10:59:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 22 Apr 2022 10:59:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1650639580; x=1650725980; bh=+aYEisS0ci 7NMOYdjImF64uoW7tyrs5MX+79lvN3ljA=; b=SCNFHx/m4M2VRL3aIWDDZzAjWO ikDCVUUHVQ/inV+LVyWoQPB47LiM4wULia0G5ezXWg4QXTm4XlSYvWFnOHJVFd7V hjmH4u1n++vv/S8iQDN7fB7x0KRMXouw1ooJqN0vJdu0EK/fnGS/Wzpt+UStLT6Q ilNg3TetfTwXNWNXdEii2mTQJzGycCfUeYgvBZG1QMdGmDx84r06xlgTZqK5AF4w 6E/gtqrpdVoqO0cubeSRrWO1VPvUW9VqWfV9L7wlhFbOjOW2ISyQRv2PMNun0u1h ty+BdSZ2Df/tMXR8x1aLuq7HyS69ClWzQK0qWVkNTfBQ5hXPxjAnXjSIGnVw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1650639580; x= 1650725980; bh=+aYEisS0ci7NMOYdjImF64uoW7tyrs5MX+79lvN3ljA=; b=b zceQ/so8EsdeA7RmA+RiIaCPZWGwMvCHqCpPDmJaIgZr1xyZAIuvvZED7pFpfcA0 HauJHzcfPeT7lBV7SeX/w2oo+D0l+Mga+KsyraOHkF2usCnPVbyIwbWEsPYCPqky A5rntHqtqYoqXulvTM4WepZ98AFcSFU2qCgRWpfyDOjd5fv5LXbEZs/Akfvm5RLG FLDg9chkz+pMxz0nFObB6PgdHBvV5u2fGzaxDOm3lUSVRfD2ulfwpDCmGT7C5oEv j+nu2CXu/EG+qvqaCQZNGvqri3mEu2ta1uHh35e+h3bvwI0IYeQZjYcEPLyAi55H ViQh/flDGHGfQ+2ivQ7YQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrtdeggdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepifhrvghgucfmjfcuoehgrhgvgheskhhrohgrhhdrtghomheq necuggftrfgrthhtvghrnhepgeehueehgfdtledutdelkeefgeejteegieekheefudeiff dvudeffeelvedttddvnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehgrhgvgheskhhrohgrhh drtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 22 Apr 2022 10:59:39 -0400 (EDT) Date: Fri, 22 Apr 2022 16:59:38 +0200 From: Greg KH To: Solomon Tan Subject: Re: Coding style operator precedence Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Fri, Apr 22, 2022 at 10:08:54PM +0800, Solomon Tan wrote: > Hey all, > > Could someone share what the coding style preference is where operator > precedence is concerned? > > I notice in the staging drivers that there are many instances where > there are parenthesis in statements where operator precedence should be > (in my opinion) obvious. Yet, there doesn't seem to be a patch to amend > it. For example: > > In vc04_services/interface/vchiq_arm/vchiq_core.c, line 2136, there is > ``` > slot_zero->master.slot_last = first_data_slot + (num_slots / 2) - 1; > ``` > It could just have been > ``` > slot_zero->master.slot_last = first_data_slot + num_slots / 2 - 1; > ``` > yet I do not see anyone patching it. Nothing is mentioned in the kernel > docs about operator precedence. Checkpatch.pl doesn't highlight it > as a coding style either. Because as-is, it is fine. > What is the concensus regarding operator precedence in kernel coding > style? The most relevant email thread I found suggests some feel the > parenthesis shouldnt be there, while others would leave it there for > readability. > https://lore.kernel.org/linux-staging/YRypyev4Ku3eI9w8@kroah.com/ Make it obvious when people read the code as we do not always remember the precedence order. We write code for people first, compilers second. thanks, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies