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 07F31C77B7D for ; Fri, 5 May 2023 20:28:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231290AbjEEU2p (ORCPT ); Fri, 5 May 2023 16:28:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230144AbjEEU2o (ORCPT ); Fri, 5 May 2023 16:28:44 -0400 Received: from smtpout.efficios.com (unknown [IPv6:2607:5300:203:b2ee::31e5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 011D040FB; Fri, 5 May 2023 13:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1683318523; bh=lOJceDItkMuBUJjwo0/e9SQZdXHqosSpw9xAH6N0hSM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=IIcIIZrYQo99YktN7rvaAwW/GoJRUepRYirU5YqtkVo6qWs3SMFtZtUxh7Eq6E6dm r+kzwA8jLWUce/l5P6XRVYkTMPGShiuwgRTIfEjcyOc1o6nur/dnB6g3kitT0PtSts dnoBFz3lXu8THYVBa1DaOT7fw9ts3f7cppPd3BYiOPVpkQmxiGZcNYtKPxvIB0ymDX KtycY6HDS14VG7/nw4MeIkwqDwL2kRt6SniOB9bsKKooiS+vl30WuLc+AVA2HpxTh7 CzL+Zi0yff5UwKXR1LjYjfZOlx8lbcUtFWfrWCCXeCPK34xSVw+IJKpHrd+qRZHpgU b+TdzSqZzqTgQ== Received: from [172.16.0.99] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4QCj231CCcz125Q; Fri, 5 May 2023 16:28:43 -0400 (EDT) Message-ID: <322d22f5-7ab0-adbd-45a0-879364d79ce8@efficios.com> Date: Fri, 5 May 2023 16:28:47 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [RFC PATCH 12/13] blk-mq.h: Fix parentheses around macro parameter use Content-Language: en-US To: Linus Torvalds Cc: Andrew Morton , linux-kernel@vger.kernel.org, Jens Axboe , linux-block@vger.kernel.org References: <20230504200527.1935944-1-mathieu.desnoyers@efficios.com> <20230504200527.1935944-13-mathieu.desnoyers@efficios.com> <3b017a9f-220d-4da8-2cf6-7f0d6175b30c@efficios.com> <3cc72a67-d648-0040-6f60-37663797e360@efficios.com> From: Mathieu Desnoyers In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On 2023-05-05 16:22, Linus Torvalds wrote: > On Fri, May 5, 2023 at 1:08 PM Mathieu Desnoyers > wrote: >> >> The reason why I think the lvalue of a "=" operator can be argued to be >> "special" is because it is simply invalid to apply many of the C >> operators to an lvalue (e.g. +, -, /, ...), > > Mathieu, you are simply objectively wrong. > > See here: > > #define m1(x) (x = 2) > #define m2(x) ((x) = 2) > > and then try using the argument "a = b" to those macros. > > Guess which one flags it as an error ("lvalue required") and which one does not? I'm glad you are proving me wrong. So it was just a lack of imagination on my end. > > m2 is the only "good" one. Yes, m1 works in 99% of all cases in > practice, but if you want a safer macro, you *will* add the > parentheses. > > So *STOP*ARGUING* based on an incorrect "lowest precedence" basis. > Even for the "lowest precedence" case, you have the *same* precedence. Yes, your example clearly shows it. > The fact is, assignment is not in any way special operation in macros, > and does not deserve - and should absolutely not have - any special > "doesn't need parentheses around argument" rules. Good point. You are right. So that strongly supports the parentheses around use of parameters as lvalues. One less special-case to care about, which is great. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com