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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0606C433FE for ; Thu, 10 Dec 2020 13:41:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AECF42311B for ; Thu, 10 Dec 2020 13:41:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389319AbgLJNlS (ORCPT ); Thu, 10 Dec 2020 08:41:18 -0500 Received: from smtprelay0062.hostedemail.com ([216.40.44.62]:42830 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2389278AbgLJNlS (ORCPT ); Thu, 10 Dec 2020 08:41:18 -0500 Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id 612FA837F253; Thu, 10 Dec 2020 13:40:37 +0000 (UTC) X-Session-Marker: 6A6F6540706572636865732E636F6D X-HE-Tag: help02_100b57b273f8 X-Filterd-Recvd-Size: 2625 Received: from XPS-9350.home (unknown [47.151.137.21]) (Authenticated sender: joe@perches.com) by omf15.hostedemail.com (Postfix) with ESMTPA; Thu, 10 Dec 2020 13:40:36 +0000 (UTC) Message-ID: <8ee5b1f0eaec9c71066027e4e130d473fe6532d7.camel@perches.com> Subject: Re: checkpatch From: Joe Perches To: David Laight , Thomas Gleixner Cc: LKML Date: Thu, 10 Dec 2020 05:40:35 -0800 In-Reply-To: <32a8677e1bcf4d69ba019bfcefc9ea59@AcuMS.aculab.com> References: <87zh2mzw3h.fsf@nanos.tec.linutronix.de> <32a8677e1bcf4d69ba019bfcefc9ea59@AcuMS.aculab.com> Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.38.1-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2020-12-10 at 09:34 +0000, David Laight wrote: > From: Joe Perches > > Sent: 10 December 2020 05:26 > > > > On Wed, 2020-12-09 at 19:13 +0100, Thomas Gleixner wrote: > > > Joe, > > > > Hi Thomas. > > > > > the below made it through my filters for some reason so I actually > > > looked and immediately wondered why checkpatch.pl did not identify this > > > as pure garbage. > > > > > >  Original mail is here: lore.kernel.org/r/69cb540a-09d5-4956-b062-071ccded7090@web.de > > > > > > Can you have a look please? Adding brackets in the middle of the code > > > for absolutely no reason is wrong to begin with and then not indenting > > > the enclosed code makes it even worse. > > > > Well, maybe something like this, but there are probably some > > drawbacks with initializations. > > Isn't the other likely problem where an extra code block > is being squeezed in after a case label without generating > a double-indent. Probably not. A common form for a case label with a brace is like the below where the code is indented. There aren't many uses where the code for the case is at the same indent level as the case. case foo: { definitions; code; break; } Another puts the break at the same indent as the case. case foo: { definitions; code; } break; The other form that's used with case statements have the brace on the line with the case: case foo: { definitions; code; break; } There are some uses where the open brace is on a separate line like the below, but checkpatch already emits a message like "open brace should be on the previous line" for it. Now another message will be emitted for the open brace. switch (foo) { case bar: