From: Andy Whitcroft <apw@shadowen.org>
To: Jan Engelhardt <jengelh@computergmbh.de>
Cc: Rogan Dawes <lists@dawes.za.net>, Paul Jackson <pj@sgi.com>,
linux-kernel@vger.kernel.org
Subject: Re: +patch Why these dot chars in scripts/checkpatch.pl?
Date: Tue, 29 Apr 2008 00:06:37 +0100 [thread overview]
Message-ID: <20080428230637.GX5401@shadowen.org> (raw)
In-Reply-To: <alpine.LNX.1.10.0804282351120.21466@fbirervta.pbzchgretzou.qr>
On Tue, Apr 29, 2008 at 12:10:03AM +0200, Jan Engelhardt wrote:
>
> On Monday 2008-04-28 22:47, Rogan Dawes wrote:
> > Paul Jackson wrote:
> >> Andy,
> >>
> >> Perhaps I'm loosing my magic regex pixie dust, but the dot '.' char
> >> in the pattern "/^.#" in the following lines looks wrong to me, as if
> >> one were trying to match pre-processor directives that were set in by
> >> one character:
> >
> > Perhaps it is because checkpatch.pl is supposed to check *patches*, which are
> > typically indented by one character (+- )?
>
> Even so, the regexes are not entirely accurate.
> Patch below.
Yeah I was under the missaprehension that whitespace was allowed after
the # but not before. That seems to be flawed. Thanks for the patch.
"Preprocessing directives are lines in your program that start with `#'.
Whitespace is allowed before and after the `#'."
> ===
> commit e08a94e334d67ac5f2437c8aba4c6ffbb058d7db
> Author: Jan Engelhardt <jengelh@medozas.de>
> Date: Tue Apr 29 00:06:42 2008 +0200
>
> checkpatch: fix recognition of preprocessor directives
>
> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 58a9494..22df611 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -355,12 +355,12 @@ sub sanitise_line {
> }
>
> # The pathname on a #include may be surrounded by '<' and '>'.
> - if ($res =~ /^.#\s*include\s+\<(.*)\>/) {
> + if ($res =~ /^.\s*#\s*include\s+\<(.*)\>/) {
> my $clean = 'X' x length($1);
> $res =~ s@\<.*\>@<$clean>@;
>
> # The whole of a #error is a string.
> - } elsif ($res =~ /^.#\s*(?:error|warning)\s+(.*)\b/) {
> + } elsif ($res =~ /^.\s*#\s*(?:error|warning)\s+(.*)\b/) {
> my $clean = 'X' x length($1);
> $res =~ s@(#\s*(?:error|warning)\s+).*@$1$clean@;
> }
> @@ -1194,7 +1194,7 @@ sub process {
>
> # if/while/etc brace do not go on next line, unless defining a do while loop,
> # or if that brace on the next line is for something else
> - if ($line =~ /(.*)\b((?:if|while|for|switch)\s*\(|do\b|else\b)/ && $line !~ /^.#/) {
> + if ($line =~ /(.*)\b((?:if|while|for|switch)\s*\(|do\b|else\b)/ && $line !~ /^.\s*#/) {
> my $pre_ctx = "$1$2";
>
> my ($level, @ctx) = ctx_statement_level($linenr, $realcnt, 0);
> @@ -1877,7 +1877,7 @@ sub process {
> }
>
> # warn about #if 0
> - if ($line =~ /^.#\s*if\s+0\b/) {
> + if ($line =~ /^.\s*#\s*if\s+0\b/) {
> CHK("if this code is redundant consider removing it\n" .
> $herecurr);
> }
> @@ -1891,14 +1891,14 @@ sub process {
> }
>
> # warn about #ifdefs in C files
> -# if ($line =~ /^.#\s*if(|n)def/ && ($realfile =~ /\.c$/)) {
> +# if ($line =~ /^.\s*#\s*if(|n)def/ && ($realfile =~ /\.c$/)) {
> # print "#ifdef in C files should be avoided\n";
> # print "$herecurr";
> # $clean = 0;
> # }
>
> # warn about spacing in #ifdefs
> - if ($line =~ /^.#\s*(ifdef|ifndef|elif)\s\s+/) {
> + if ($line =~ /^.\s*#\s*(ifdef|ifndef|elif)\s\s+/) {
> ERROR("exactly one space required after that #$1\n" . $herecurr);
> }
>
> @@ -1972,7 +1972,7 @@ sub process {
> # use of NR_CPUS is usually wrong
> # ignore definitions of NR_CPUS and usage to define arrays as likely right
> if ($line =~ /\bNR_CPUS\b/ &&
> - $line !~ /^.#\s*define\s+NR_CPUS\s+/ &&
> + $line !~ /^.\s*#\s*define\s+NR_CPUS\s+/ &&
> $line !~ /^.\s*$Declare\s.*\[[^\]]*NR_CPUS[^\]]*\]/)
> {
> WARN("usage of NR_CPUS is often wrong - consider using cpu_possible(), num_possible_cpus(), for_each_possible_cpu(), etc\n" . $herecurr);
next prev parent reply other threads:[~2008-04-28 23:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-28 20:31 Why these dot chars in scripts/checkpatch.pl? Paul Jackson
2008-04-28 20:47 ` Rogan Dawes
2008-04-28 20:51 ` Paul Jackson
2008-04-28 22:10 ` Jan Engelhardt
2008-04-28 23:06 ` Andy Whitcroft [this message]
2008-04-29 9:51 ` +patch " Segher Boessenkool
2008-04-28 23:02 ` Andy Whitcroft
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080428230637.GX5401@shadowen.org \
--to=apw@shadowen.org \
--cc=jengelh@computergmbh.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lists@dawes.za.net \
--cc=pj@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox