[lkml]   [2020]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2] checkpatch: fix missing whitespace in formatted email
On Tue, Oct 13, 2020 at 12:27 PM Joe Perches <> wrote:
> On Tue, 2020-10-13 at 12:06 +0530, Dwaipayan Ray wrote:
> > Commit 0c01921e56f9 ("checkpatch: add new warnings to author signoff
> > checks.") introduced new checks for author sign off. The format_email
> > procedure was modified to add comment blocks to the formatted email. But
> > no space was added between the email address and mail comment.
> >
> > This causes wrong email formatting in cases where the email is in the form
> > " (Comment block)". The space between the address and
> > comment block is removed, which causes incorrect parsing of the
> > formatted email.
> >
> > An evaluation on checkpatch brought up this case. For example,
> > on commit 1129d31b55d5 ("ima: Fix ima digest hash table key calculation"),
> > the following warning was reported:
> >
> > WARNING:BAD_SIGN_OFF: email address ' (big endian
> > system concerns)' might be better as ' endian
> > system concerns)'
> Strictly, a comment or multiple comments can exist
> in any part of an email
> "John (Jon) Smith (Smitty) <jsmith@domain.tld> (tld is the best tld)
> > Add a single space in between the address and comment when the
> > extracted comment is not empty.
> So after the address is not necessarily the best
> location for a comment.

Yes I agree and in cases like that the check works perfectly.
But now consider the case when the name is empty:

jsmith@domain.tld (tld is the best tld).

In this case when the formatted email is generated, we have
the following: "jsmith@domain.tld(tld is the best tld)".
If this email is parsed again, the entire part is parsed as the email address,
which causes a mismatch later on.

It is for only this case that an extra white space is needed for the
parsing, probably because of how the comment is captured, for emails
with empty names:
$formatted_email =~ /(\S+\@\S+)(.*)$/
So it depends on the whitespace after address to demarcate the comment.

Some more examples of what I intend to solve:
'<> [5.3+]'
'<> # v5.7+'
' (big endian system concerns)'


 \ /
  Last update: 2020-10-13 09:36    [W:0.044 / U:1.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site