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 D753EC433F5 for ; Fri, 20 May 2022 17:24:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352244AbiETRY6 (ORCPT ); Fri, 20 May 2022 13:24:58 -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-Stat-Signature: egq551txxc3afjxpmwups4w9xq1sq7cr X-Rspamd-Server: rspamout05 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Session-ID: U2FsdGVkX1+q3qK2ENX7TEoV39UpiiLOyeJIHyMH308= X-HE-Tag: 1653067481-758101 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