Re: [PATCH v2] checkpatch: Fix the usage of capture group ( ... )

[Lukas Bulwahn]

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/]+` matched.
> 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@xxxxxxxxx>
> Tested-by: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx>
> Signed-off-by: Mrinal Pandey <mrinalmni@xxxxxxxxx>
> ---
> 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.

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?

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.


Lukas