@@ -1132,11 +1132,10 @@ sub possible {
case|
else|
asm|__asm__|
- do|
- \#|
- \#\#
+ do
)(?:\s|$)|
- ^(?:typedef|struct|enum)\b
+ ^(?:typedef|struct|enum)\b|
+ ^\#
)}x;
warn "CHECK<$possible> ($line)\n" if ($dbg_possible > 2);
if ($possible !~ $notPermitted) {
@@ -1146,7 +1145,7 @@ sub possible {
if ($possible =~ /^\s*$/) {
} elsif ($possible =~ /\s/) {
- $possible =~ s/\s*$Type\s*//g;
+ $possible =~ s/\s*(?:$Type|\#\#)\s*//g;
for my $modifier (split(' ', $possible)) {
if ($modifier !~ $notPermitted) {
warn "MODIFIER: $modifier ($possible) ($line)\n" if ($dbg_possible);
The mechanism to find possible type tokens can sometimes be confused and go into an infinite loop. This happens for example in QEMU for a line that looks like uint## BITS ##_t S = _S, T = _T; \ uint## BITS ##_t as, at, xs, xt, xd; \ Because the token pasting operator does not have a space before _t, it does not match $notPermitted. However, (?x) is turned on in the regular expression for modifiers, and thus ##_t matches the empty string. As a result, annotate_values goes in an infinite loop. The solution is simply to remove token pasting operators from the string before looking for modifiers. In the example above, the string uintBITS_t will be evaluated as a candidate modifier. This is not optimal, but it works as long as people do not write things like a##s##m, and it fits nicely into sub possible. For a similar reason, \# should be rejected always, even if it is not at end of line or followed by whitespace. The same patch was sent to the Linux kernel mailing list. Reported-by: Aleksandar Markovic <amarkovic@wavecomp.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- scripts/checkpatch.pl | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)