Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2692266rwd; Fri, 19 May 2023 08:58:12 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7YtasXK2Qsg9Vxy1f9o5qQbY4hDHYYj6HrMPajt9H5mu8EjYyT8plRKwCShaGcPHNyY4W3 X-Received: by 2002:a05:6a00:2e21:b0:627:e49a:871a with SMTP id fc33-20020a056a002e2100b00627e49a871amr3721789pfb.23.1684511892339; Fri, 19 May 2023 08:58:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684511892; cv=none; d=google.com; s=arc-20160816; b=S2o2lOMKWv2fF+G0UnQG7kYn85slIT/Fg6AMGcVEKJRRQ1d+PQ09lNY8LaSqbGGghi SVy9ETMKRj3RFTl92KwhqcaH0aqdMG3GDfyjXEA6fWikODVA6/sKqar7scglmJs8yMmg At++ZjL67vmNBS6cxc+x3IxEBPFY6GYhigeS3+Mu3LUgOOZ6gR+OAPyCFs61YnydIeZH F/fnT0IhXgSM1mq1BNuWyMJdVUfoUsGhqRxl+u1x+vyd6pM46Ezxi4O+rGB4GT+1IQfb lQhya+DaV37piOFIMnxIpYeoy63zBX66ozicPO4jVxG+nWErmLxrI8ru8NR8C8iHctWJ 7mrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature:dkim-filter; bh=JXzqn/kBG5UL0/TLKHrauul40S0pyWarjFgX8Y+MmPA=; b=wJSgWaP6ktrzPqyCvZu0fYc3YSoNC4bBkvylROkiBmE3AXCyg6NOeAoVeoslq7HI6x XqVBgIPdISema14Ln5khQZUvBPXOteCFsaky9gqq2LlfHM8jU4FYJA7ht4K4bniKsMMF 4upkzmnxhI7jMtW8WIPMoJ/ZM7spwlwr2KEuosL+0G3C1ds+nxpGM7ba38xnTDi0E4IQ fnS+TEKEZxlwfT2R9ec+azWPROvuRj4QYZJaDsAVUXLEciTQbYrxRmrwcVDexoWiGT0v FnxLxodyc6cfCOx9pQERuhOIIzPbguA74NPX7q9D0aDtV2dyJG2Y3N9/WJq5l0T1qxX+ NlvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lwn.net header.s=20201203 header.b=NxYbW5ZZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a29-20020aa794bd000000b0063c56e46f9esi4146208pfl.294.2023.05.19.08.57.58; Fri, 19 May 2023 08:58:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@lwn.net header.s=20201203 header.b=NxYbW5ZZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232314AbjESPXv (ORCPT + 99 others); Fri, 19 May 2023 11:23:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229693AbjESPXu (ORCPT ); Fri, 19 May 2023 11:23:50 -0400 Received: from ms.lwn.net (ms.lwn.net [45.79.88.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 554B819F; Fri, 19 May 2023 08:23:49 -0700 (PDT) Received: from localhost (unknown [IPv6:2601:281:8300:73::5f6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id E27217C0; Fri, 19 May 2023 15:23:48 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net E27217C0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203; t=1684509829; bh=JXzqn/kBG5UL0/TLKHrauul40S0pyWarjFgX8Y+MmPA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NxYbW5ZZGwsX+RiKZST2x6WGizQQtEBsqBkko8/i14a0XHfYPCjt7+mp4OY2lRdai 6+RUsWtVRSnLtq30tBmy3NYxTRQE36EO+aB2FD5s2FVl49WcMSDgBO46SHauL0EcIk rIgc02IXxThDcfpPe3gpU/pK86BwRFhKXLrJJBZYzZBb7LKbPughD4DVaYAoS/Z2Cw ARuUlRpykVhhX5pIlzpKM/533GB1mI6c898EE8BgWfOQpg6xNGj/kXTgW2Sa9jEZ5t 56HZBrMY1uY+5a7WxjszatZivpkWOHCnQ/ZTBYcrGwM7GBc7W26MPbgbaLc/EremJW DPAVO7Q9I6Agw== From: Jonathan Corbet To: Mathieu Desnoyers , Linus Torvalds Cc: linux-kernel@vger.kernel.org, Mathieu Desnoyers , Steven Rostedt , linux-doc@vger.kernel.org Subject: Re: [RFC PATCH] Documentation: Document macro coding style In-Reply-To: <20230511152951.1970870-1-mathieu.desnoyers@efficios.com> References: <20230511152951.1970870-1-mathieu.desnoyers@efficios.com> Date: Fri, 19 May 2023 09:23:48 -0600 Message-ID: <87y1lkmjjv.fsf@meer.lwn.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mathieu Desnoyers writes: > Document the kernel coding style for macros with parameters. > > The purpose of this text is to be used as a reference to gradually > transition towards macros with a more consistent style, and eliminate > subtle bugs that can creep up due to missing parentheses, and generally > remove the need to think and argue about C operator precedence. > > This is based on a mailing list discussion with Linus. > > Link: https://lore.kernel.org/lkml/CAHk-=wjfgCa-u8h9z+8U7gaKK6PnRCpws1Md9wYSSXywUxoUSA@mail.gmail.com/ > Link: https://lore.kernel.org/lkml/CAHk-=wjzpHjqhybyEhkTzGgTdBP3LZ1FmOw8=1MMXr=-j5OPxQ@mail.gmail.com/ > Link: https://lore.kernel.org/lkml/CAHk-=wh-x1PL=UUGD__Dv6kd+kyCHjNF-TCHGG9ayLnysf-PdQ@mail.gmail.com/ > Link: https://lore.kernel.org/lkml/CAHk-=wg27iiFZWYmjKmULxwkXisOHuAXq=vbiazBabgh9M1rqg@mail.gmail.com/ > Signed-off-by: Mathieu Desnoyers > Cc: Linus Torvalds > Cc: Steven Rostedt > Cc: Jonathan Corbet > Cc: linux-doc@vger.kernel.org > --- > Documentation/process/coding-style.rst | 152 ++++++++++++++++++++++++- > 1 file changed, 151 insertions(+), 1 deletion(-) So this looks generally OK to me. I really like to see some reviews / acks on coding-style patches, though; I don't feel like I should be the arbiter of kernel coding style. One little comment below > diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst > index 6db37a46d305..3cf62c91d91c 100644 > --- a/Documentation/process/coding-style.rst > +++ b/Documentation/process/coding-style.rst > @@ -819,10 +819,160 @@ Macros with multiple statements should be enclosed in a do - while block: > > #define macrofun(a, b, c) \ > do { \ > - if (a == 5) \ > + if ((a) == 5) \ > do_this(b, c); \ > } while (0) > > +Always use parentheses around macro arguments, except for the situations listed > +below. > + > +Examples where parentheses are required around macro arguments: > + > +.. code-block:: c > + > + #define foo(a, b) \ > + do { \ > + (a) = (b); \ > + } while (0) > + > +.. code-block:: c > + > + #define foo(a) \ > + do { \ > + (a)++; \ > + } while (0) > + > +.. code-block:: c > + > + #define cmp_gt(a, b) ((a) > (b)) > + > +.. code-block:: c > + > + #define foo(a) do_this(!(a)) > + > +.. code-block:: c > + > + #define foo(a) do_this(*(a)) > + > +.. code-block:: c > + > + #define foo(a) do_this(&(a)) > + > +.. code-block:: c > + > + #define get_member(struct_var) do_this((struct_var).member) > + > +.. code-block:: c > + > + #define deref_member(struct_ptr) do_this((struct_ptr)->member) I wonder if we really need to give all of these examples? We've already said "always put parentheses except in a few cases" - I would think that would be enough. > +Situations where parentheses should not be added around arguments, when: For these, it would be nice to say *why* parentheses shouldn't be added; helping readers understand the reasoning might have more benefit than imparting a set of rules. Thanks, jon