[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f5d8124e54a50480b0a9fa638787bc29b6e09854.camel@perches.com>
Date: Sat, 19 Sep 2020 11:19:25 -0700
From: Joe Perches <joe@...ches.com>
To: Lukas Bulwahn <lukas.bulwahn@...il.com>
Cc: Dwaipayan Ray <dwaipayanray1@...il.com>,
linux-kernel-mentees@...ts.linuxfoundation.org, apw@...onical.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] checkpatch: extend author Signed-off-by check for split
From: header
On Sat, 2020-09-19 at 20:12 +0200, Lukas Bulwahn wrote:
>
> On Sat, 19 Sep 2020, Joe Perches wrote:
>
> > On Sat, 2020-09-19 at 13:42 +0530, Dwaipayan Ray wrote:
> > > Checkpatch did not handle cases where the author From: header
> > > was split into two lines. The author string went empty and
> > > checkpatch generated a false NO_AUTHOR_SIGN_OFF warning.
> >
> > It's good to provide an example where the current code
> > doesn't work.
> >
>
> Joe, as this is a linux-kernel-mentees patch, we discussed that before
> reaching out to you; you can find Dwaipayan's own evaluation here:
>
> https://lore.kernel.org/linux-kernel-mentees/CABJPP5BOTG0QLFSaRJTb2vAZ_hJf229OAQihHKG4sYd35i_WMw@mail.gmail.com/
>
> Dwaipayan, Joe's comment is still valid; it would be good to describe
> the reasons why patches might have split lines (as far as see, long
> encodings for non-ascii names).
>
> I will run my own evaluation of checkpatch.pl before and after patch
> application on Monday and then check if I can confirm Dwaipayan's results.
>
> > It likely would be better to do this by searching forward for
> > any extension lines after a "^From:' rather than searching
> > backwards as there can be any number of extension lines.
> >
>
> Just to sure what you are talking about...
>
> You mean just to access the next line through the lines array, rather
> than using prevheader and trying to decode that one line twice.
>
> I agree the logic is a bit redundant and complicated at the moment.
>
> Once prevheader is non-empty, it already clear that author is '' and
> prevheader decodes with that match, because that is the only way to
> make prevheader non-empty in the first place; at least as far I see it
> right now.
Yeah, something like this (completely untested):
---
scripts/checkpatch.pl | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3e474072aa90..2c710d05b184 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2679,9 +2679,13 @@ sub process {
}
# Check the patch for a From:
- if (decode("MIME-Header", $line) =~ /^From:\s*(.*)/) {
+ if ($line =~ /^From:\s*(.*)/i) {
$author = $1;
- $author = encode("utf8", $author) if ($line =~ /=\?utf-8\?/i);
+ my $curline = $linenr;
+ while (defined($rawlines[$curline] && $rawlines[$curline++] =~ /^ \s*(.*)/) {
+ $author .= $1;
+ }
+ $author = encode("utf8", $author) if ($author =~ /=\?utf-8\?/i);
$author =~ s/"//g;
$author = reformat_email($author);
}
Powered by blists - more mailing lists