[Linux-kernel-mentees] [PATCH v2] checkpatch: Fix the usage of capture group ( ... )
mrinalmni at gmail.com
Tue Jul 14 07:37:03 UTC 2020
On Tue, Jul 14, 2020 at 11:18 AM Lukas Bulwahn <lukas.bulwahn at gmail.com>
> On Tue, 14 Jul 2020, Mrinal Pandey wrote:
> > The usage of "capture group (...)" in the immediate condition after `&&`
> > results in `$1` being uninitialized. This issues a warning "Use of
> > uninitialized value $1 in regexp compilation at ./scripts/checkpatch.pl
> > line 2638".
> > I noticed this bug while running checkpatch on the set of commits from
> > v5.7 to v5.8-rc1 of the kernel on the commits with a diff content in
> > their commit message.
> > This bug was introduced in the script by commit e518e9a59ec3
> > ("checkpatch: emit an error when there's a diff in a changelog"). It has
> > been in the script since then.
> > The author intended to store the match made by capture group in variable
> > `$1`. This should have contained the name of the file as `[\w/]+`
> > However, this couldn't be accomplished due to usage of capture group and
> > `$1` in the same regular expression.
> > Fix this by placing the capture group in the condition before `&&`.
> > Thus, `$1` can be initialized to the text that capture group matches
> > thereby setting it to the desired and required value.
> > Reviewed-by: Lukas Bulwahn <lukas.bulwahn at gmail.com>
> > Tested-by: Lukas Bulwahn <lukas.bulwahn at gmail.com>
> > Signed-off-by: Mrinal Pandey <mrinalmni at gmail.com>
> > ---
> > Changes since v1:
> > Add Reviewed-by and Tested-by tag
> Usually, the maintainers pick up those tags when they apply a patch to
> their tree, and the patch authors do not need to add those tags and resend
> the patch as a new version on the mailing list.
Thank you for your insight. I'll keep this in mind.
> Mrinal, can you please go through and check the kernel documentation on
> submitting patches and find the places where it is pointed out that the
> maintainers usually apply those tags and the authors usually do not need
> to resend a new version of the patch with the tags applied?
I read through Submitting patches
and a few related pieces of documentation but
couldn't infer this information.
> If you cannot find such a statement in the documentation, please let us
> know where it would ideally added in the documentation. We can then create
> a patch for that together.
The statement might be placed under Respond to review comments
it could further contain some information about how to send a new version
of the patch.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Linux-kernel-mentees