From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753195AbcIDNvw (ORCPT ); Sun, 4 Sep 2016 09:51:52 -0400 Received: from mout.web.de ([212.227.15.3]:57306 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752469AbcIDNvt (ORCPT ); Sun, 4 Sep 2016 09:51:49 -0400 Subject: Re: Clarification for source code formatting around jump labels To: Daniel Borkmann References: <57CAFFDC.4030606@iogearbox.net> <20160903.230607.1667562673788737377.davem@davemloft.net> <1365a588-c7c7-717c-1e3d-ceabd71e8479@users.sourceforge.net> <20160903.235916.1892276070318494855.davem@davemloft.net> <57CBEFEA.3080007@iogearbox.net> Cc: Jonathan Corbet , David Miller , sparclinux@vger.kernel.org, Adam Buchbinder , Alexei Starovoitov , Rabin Vincent , linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Julia Lawall , Paolo Bonzini , linux-doc@vger.kernel.org, Jean Delvare From: SF Markus Elfring Message-ID: <50edcf58-112e-0b89-4265-7c39d2f147ca@users.sourceforge.net> Date: Sun, 4 Sep 2016 15:50:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <57CBEFEA.3080007@iogearbox.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:1F/nQdaVSP/TSZzI99iWCZSTpAuKdB21Ej9LavDgiUCnQbaysE1 i2Uzy5tMsRIpTfvVSiHRe6Q8rmg5EnC7vPzXrtbvjF4OYieUZ49rgZ/jCjxrpDjdi7z1hhO SAcf3IHvWQeduPqjEyiOTRDgtBhgCynu59i0F4e/i3Q0BqVZbHGvo+pKO73Domi537lYTLF z3/xGMrRzVcyzC4RJUr/Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:lakNnJThbyQ=:BoejSN7TbYHn/vhpjgiAKP /zduk/d5XhGO6haUfdLredPDitlTPSoRJ8mX7G0YChlHBj/gFzNgWpKKzBEoVB2GQpll9KMfT qKbeT+vrCkZlEzZyO2VXdHNIJAP9vhnboOG3kK1ymgVD6lwrwxib5RmiSB7X8Dg2xebmm5/jq BbMsxXj7auUyuljVbAI4zN+fiF86vIi5824b1PaNNeX2288B8XGNNWx56HqiFNPCBT+3jTW1H xIQSPpogk4u5ADA2M6Qu3Ee4mpb0a5JiR6G1Nct1Ua0VR3oKnYLQIaL4PpXx6iCcUbtxINQHo HKVFHV7/fHmamQr+85RXQ8gl3gbMReQ8plbPpn/WmZTYL3FCBGK7VgEk7aqS8ifTKq/TEqspd Nb9ijEHfM9mpifePga3TytQlLeU/B6zAdbzt6CoJMbjsgb8HqK+eP/k3pF7wzWiQq2hVcW2P6 Y0TiRR38cbbZzpvj2Qe32N2ll0yfQXKnzP9NzZFyG+mKaWGmEGvmNeOzWStBDCRs05XsZXznS adUTK2rNCmoz/IdnaYXqqKsUSJjUOHqLeSFCf7gc5DntcPEyDKJ3IhqA0DR0DyzuLvKU0SO6z uHoVgi/7XTbzDgE8b/CTc5avVKzQxLBOh2F5uD1OXAlBs9WWme3SZoawwb+xxd+z6Z94WQmJI vpkdALlXDmimu0RAH/cbeOFXOWXl8xpuVCX6YkJDINw6o5ne9ugDA6uoH891z/m9NwIfFwhgC eEdEtek8DS9JnqHTL1//pFHcBbzTLHY28RzrYkvJGSegVrbYHQu4Zo1PptwW5SSMLC/Edj0jJ HmLqR1e Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> I am just curious on how much further software development "fun" the recent update >> by a topic like "CodingStyle: Clarify and complete chapter 7" will trigger. > > I don't want to drag this thread onwards for (way) too long, but clearly "it is > advised to indent labels with a single space (not tab)" (from diff in above commit) How do you think about the reason (which you omitted from your quotation) for this advice? “…, so that "diff -p" does not confuse labels with functions. …” > doesn't really reflect the majority of kernel practice we have in-tree today and > actually rather adds more confusion than any clarification whatsoever: > > $ git grep -n "^\ [a-z_]*:" -- '*.[ch]' | wc -l > 4919 > $ git grep -n "^[a-z_]*:" -- '*.[ch]' | wc -l > 54686 So there is a mixture already. > A CodingStyle document should document what's regarded as a general consensus of > kernel coding practices, and thus should represent the /majority/ of coding style, > which (if I didn't screw up my git-grep line completely) 1. Is the used character class specification complete in the shown regular expression? 2. I guess that you should use the regex operator "plus" (instead of the asterisk). 3. Would you like to try another source code analysis out which can be a bit safer with the usage of the semantic patch language? > above 9% does not really reflect at all. How tolerant are you for using an extra space character before the identifier for a jump label? > So, new folks starting with kernel hacking reading this are rather misguided, > and code-wise it just adds up to have more inconsistencies from new patches, > or worse, have noisy patches (like this one) flying around that try to > brute-force everything into this advice. In which ways would you prefer that the style specifications should be clarified further? Where should source code become more consistent? Regards, Markus