From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
To: Aditya Srivastava <yashsri421@gmail.com>
Cc: joe@perches.com, linux-kernel@vger.kernel.org,
linux-kernel-mentees@lists.linuxfoundation.org,
lukas.bulwahn@gmail.com, dwaipayanray1@gmail.com
Subject: Re: [PATCH v3] checkpatch: fix false positives in REPEATED_WORD warning
Date: Fri, 23 Oct 2020 21:06:42 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.2010232104150.11676@felia> (raw)
In-Reply-To: <20201023133828.19609-1-yashsri421@gmail.com>
On Fri, 23 Oct 2020, Aditya Srivastava wrote:
> Presence of hexadecimal address or symbol results in false warning
> message by checkpatch.pl.
>
> For example, running checkpatch on commit b8ad540dd4e4 ("mptcp: fix
> memory leak in mptcp_subflow_create_socket()") results in warning:
>
> WARNING:REPEATED_WORD: Possible repeated word: 'ff'
> 00 00 00 00 00 00 00 00 00 2f 30 0a 81 88 ff ff ........./0.....
>
> Similarly, the presence of list command output in commit results in
> an unnecessary warning.
>
> For example, running checkpatch on commit 899e5ffbf246 ("perf record:
> Introduce --switch-output-event") gives:
>
> WARNING:REPEATED_WORD: Possible repeated word: 'root'
> dr-xr-x---. 12 root root 4096 Apr 27 17:46 ..
>
> Here, it reports 'ff' and 'root to be repeated, but it is in fact part
> of some address or code, where it has to be repeated.
>
> In these cases, the intent of the warning to find stylistic issues in
> commit messages is not met and the warning is just completely wrong in
> this case.
>
> To avoid these warnings, add additional regex check for the
> directory permission pattern and avoid checking the line for this
> class of warning. Similarly, to avoid hex pattern, check if the word
> consists of hex symbols and skip this warning if it is not among the
> common english words formed using hex letters.
>
> A quick evaluation on v5.6..v5.8 showed that this fix reduces
> REPEATED_WORD warnings from 2797 to 907.
>
> A quick manual check found all cases are related to hex output or
> list command outputs in commit messages.
>
> Signed-off-by: Aditya Srivastava <yashsri421@gmail.com>
I think this strategy now makes sense and has the right complexity for a
good heuristics in this case.
Nice job, Aditya.
Are you ready for a next challenge of this kind? Would you like to work on
further rules that can be improved with your evaluation approach?
Lukas
> ---
> scripts/checkpatch.pl | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 9b9ffd876e8a..3bd8205c48d8 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3051,7 +3051,9 @@ sub process {
> }
>
> # check for repeated words separated by a single space
> - if ($rawline =~ /^\+/ || $in_commit_log) {
> +# avoid false positive from list command eg, '-rw-r--r-- 1 root root'
> + if (($rawline =~ /^\+/ || $in_commit_log) &&
> + $rawline !~ /[bcCdDlMnpPs\?-][rwxsStT-]{9}/) {
> while ($rawline =~ /\b($word_pattern) (?=($word_pattern))/g) {
>
> my $first = $1;
> @@ -3065,6 +3067,17 @@ sub process {
> next if ($first ne $second);
> next if ($first eq 'long');
>
> + # avoid repeating hex occurrences like 'ff ff fe 09 ...'
> + my @non_hex_words = (
> + "add", "added", "ace", "aced", "bad", "be", "bed", "bead",
> + "beaded", "bedded", "cab", "cabbed", "cede", "ceded",
> + "dead", "deaf", "deb", "decade", "deed", "deface", "defaced", "efface",
> + "effaced", "face", "faced", "fade", "faded", "fed", "fee", "feed"
> + );
> + if ($first =~ /\b[0-9a-f]{2,}\b/) {
> + next if (!grep(/^$first$/, @non_hex_words));
> + }
> +
> if (WARN("REPEATED_WORD",
> "Possible repeated word: '$first'\n" . $herecurr) &&
> $fix) {
> --
> 2.17.1
>
>
next prev parent reply other threads:[~2020-10-23 19:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 13:38 Aditya Srivastava
2020-10-23 19:06 ` Lukas Bulwahn [this message]
2020-10-23 20:19 ` Joe Perches
2020-10-24 13:24 ` Aditya
2020-10-24 15:33 ` Joe Perches
2020-10-24 18:12 ` Aditya
2020-10-25 5:51 ` Lukas Bulwahn
2020-10-25 6:06 ` Joe Perches
2020-10-25 6:11 ` Lukas Bulwahn
2020-10-25 10:01 ` Aditya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.2010232104150.11676@felia \
--to=lukas.bulwahn@gmail.com \
--cc=dwaipayanray1@gmail.com \
--cc=joe@perches.com \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yashsri421@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®