Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp717040ioo; Sat, 21 May 2022 11:53:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxaQSaWAUSUU+OWw1TdXFz4o26jU5Er8hS3ACBWV/Fu4B3SzQKb2rGbXl/l8oF/+0bqQaNn X-Received: by 2002:a17:907:2cc4:b0:6fe:1c72:7888 with SMTP id hg4-20020a1709072cc400b006fe1c727888mr13832074ejc.373.1653159221217; Sat, 21 May 2022 11:53:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653159221; cv=none; d=google.com; s=arc-20160816; b=bIxsaTZQQ/ba7XdCiebsBJxI/NSRr37xlSbhrLAWb5/MihjkMenM31xe9YH38L86yc RZUCgiQ2lFWeBJen683WToo/XJmlhSKNKnS+gtfdJddbs8D6IlBSfxo2a/T5/GJj4fW2 Dv5PMyQWieco9PCSFwbe2GJOqTgGaWiRM+p+vf84XIsTqHqkEeOXbsFtl1Dfdosg8ybQ vsd+nT50PpAA8tUyPQzAAPl4kZP3Mqmh2ja3wruGA1VA0G6A380ZF2Uy3EajFhfed/eU /A0WlkDGo5Cequ6DmZOCB6D7fqd9G4MrNFgfcJrTP5OzLjq943JNH75AtqGYZF4Gk+9M fvDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=+47gD8HPQufEYFQ6zxB5XGfWfQ1InoH/sbHT1pUZ7LQ=; b=xkJ6Wawtap+rDZvJSHKXd9kEddOmryWBXLgFsBQnA7oUxa+pWPKWMvAxM1+f2UbiRg z8ZNm1SDWfGm+3PrykCD50QUTXUCkJBhK0OVQS76zlJx4QjsMR8bLEPtwlveXC+ToKBw ZUJyVGh1WybuJKTBrBzUaQzpdK3qCxZH3lcT27IF6uY1w83ZymJiklk/ECx+JToryBnD RykBnuuqlR4eYxdPR6D8dWWUOFZk4JgsdAaM95pFVGiLvfrUCNxmej03Yh5dbITofF59 Jeq6rumanT2GgtF2DaUrED7PDn/eQnc9aTdJLXmu1LB0rKIUsc6Kwh68IzVK2gJ0I0P9 36vA== ARC-Authentication-Results: i=1; mx.google.com; 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 ga32-20020a1709070c2000b006f3a79245c6si13532948ejc.941.2022.05.21.11.53.15; Sat, 21 May 2022 11:53:41 -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; 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 S1352241AbiETRY4 (ORCPT + 99 others); Fri, 20 May 2022 13:24:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352176AbiETRYt (ORCPT ); Fri, 20 May 2022 13:24:49 -0400 Received: from relay3.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 48C22187DA4 for ; Fri, 20 May 2022 10:24:48 -0700 (PDT) Received: from omf18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 1047A819FC; Fri, 20 May 2022 17:24:44 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: joe@perches.com) by omf18.hostedemail.com (Postfix) with ESMTPA id 90A222F; Fri, 20 May 2022 17:24:41 +0000 (UTC) Message-ID: <5be32ddf7688db38408466315a80e03e9af7ac40.camel@perches.com> Subject: Re: [PATCH v2 4/5] clang-format: Fix empty curly braces From: Joe Perches To: Miguel Ojeda , =?ISO-8859-1?Q?Micka=EBl_Sala=FCn?= Cc: Miguel Ojeda , Andy Whitcroft , Brian Norris , Dwaipayan Ray , "Jason A . Donenfeld" , Kees Cook , Konstantin Meskhidze , Lukas Bulwahn , Nathan Chancellor , Nick Desaulniers , Paul Moore , Tom Rix , linux-kernel , llvm@lists.linux.dev Date: Fri, 20 May 2022 10:24:40 -0700 In-Reply-To: References: <20220506160106.522341-1-mic@digikod.net> <20220506160106.522341-5-mic@digikod.net> Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.40.4-1ubuntu2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 90A222F X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_SPF_HELO, KHOP_HELO_FCRDNS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_NONE,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.6 X-Stat-Signature: egq551txxc3afjxpmwups4w9xq1sq7cr X-Rspamd-Server: rspamout05 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Session-ID: U2FsdGVkX1+q3qK2ENX7TEoV39UpiiLOyeJIHyMH308= X-HE-Tag: 1653067481-758101 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 On Fri, 2022-05-20 at 19:15 +0200, Miguel Ojeda wrote: > On Fri, May 6, 2022 at 6:00 PM Micka?l Sala?n wrote: > > > > SplitEmptyFunction [1] should be false to not add a new line in an empty > > function body. This follows the current kernel coding style. > > I don't think this is correct. Checking headers in `include/linux/`, I > see ~70 using {} (when not in the same line as the signature), and > ~700 in different lines. In `kernel/`, it is even more pronounced: 4 > vs. ~200. > > Am I missing something? historic vs recent uses ? I think it's mostly a 'don't care' style. It's not like there's a significant line count advantage. Sometimes there is though for blocks like #if CONFIG_FOO void foo1(...); void foo2(...); ... void fooN(...); #else static inline void foo1(...) {} static inline void foo2(...) {} ... static inline void fooN(...) {} #endif