|SUCCESS| devtools: fix regex matching literal plus in patches

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/163592

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-06

I will review this patch against the DPDK coding standards and contribution guidelines.

commit fba5af82adc8e7d15e9a8b3d4c5f2e6a7b8c9d0e
Author: Thomas Monjalon <thomas at monjalon.net>
Subject: [PATCH] devtools: fix regex matching literal plus in patches

This patch fixes incorrect regular expressions in checkpatches.sh that
were matching the start of any line instead of only lines beginning with
a literal '+' character in diff output.

> diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
> index 1c6099ac82..f5dd77443f 100755
> --- a/devtools/checkpatches.sh
> +++ b/devtools/checkpatches.sh
> @@ -321,10 +321,10 @@ check_experimental_tags() { # <patch>
>  		current_file = "";
>  		ret = 0;
>  	}
> -	/^+++ b\// {
> +	/^[+][+][+] b\// {
>  		current_file = $2;
>  	}
> -	/^+.*__rte_experimental/ {
> +	/^[+].*__rte_experimental/ {
>  		if (current_file ~ ".c$" ) {
>  			print "Please only put __rte_experimental tags in " \
>  				"headers ("current_file")";

[ ... ]

> @@ -351,10 +351,10 @@ check_internal_tags() { # <patch>
>  		current_file = "";
>  		ret = 0;
>  	}
> -	/^+++ b\// {
> +	/^[+][+][+] b\// {
>  		current_file = $2;
>  	}
> -	/^+.*__rte_internal/ {
> +	/^[+].*__rte_internal/ {
>  		if (current_file ~ ".c$" ) {
>  			print "Please only put __rte_internal tags in " \
>  				"headers ("current_file")";

The fix correctly addresses the regex issue by using character classes
[+] instead of bare + characters. The [+] notation unambiguously matches
a literal plus sign in awk ERE, preventing it from being interpreted as
a quantifier.

Does the original buggy pattern /^+/ actually match the start of any
line in awk? In Extended Regular Expressions, a bare + at the start of
a pattern following ^ would typically be a syntax error since + is a
quantifier requiring a preceding expression. Can you confirm this
behaves as described in the commit message across different awk
implementations (gawk, mawk, busybox awk)?

The fix itself is correct and follows the proper approach for matching
literal characters that have special meaning in regex. The patch
improves the robustness of the validation scripts.