From: Benny Halevy <bhalevy@panasas.com>
To: Andy Whitcroft <apw@shadowen.org>
Cc: Marcin Slusarz <marcin.slusarz@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: bug in checkpatch (on pointers to typedefs?)
Date: Mon, 11 Feb 2008 18:58:08 +0200 [thread overview]
Message-ID: <47B07EA0.7010708@panasas.com> (raw)
In-Reply-To: <20080211164046.GI11671@shadowen.org>
On Feb. 11, 2008, 18:40 +0200, Andy Whitcroft <apw@shadowen.org> wrote:
> On Mon, Feb 11, 2008 at 06:05:48PM +0200, Benny Halevy wrote:
>> I saw this too with checkpatch.pl version 0.12
>> It seems like checkpatch.pl knows only about types derived
>> from @typeList by build_types.
>>
>> Example below...
>>
>> Benny
>>
>> $ cat <<EOF | scripts/checkpatch.pl -
>> Signed-off-by: john@smith.net
>> ---
>> diff a/f.c b/f.c
>> --- a/f.c
>> +++ b/f.c
>> @@ -1,0 +1,2 @@
>> +foo(int a, my_uint32 *);
>> +bar(int a, my_uint32_t *);
>
> But that isn't actually syntactically correct code is it? You have types
> as parameters like a function declaration, but no return type. So there
> is no hint to checkpatch that this is a function declaration and therefore
> the parameters are not expected to be types, nor are they checked as such.
>
> The following diff is clean on the latest version of checkpatch:
>
> Signed-off-by: john@smith.net
> ---
> diff a/f.c b/f.c
> --- a/f.c
> +++ b/f.c
> @@ -1,0 +1,2 @@
> +void foo(int a, my_uint32 *);
> +int bar(int a, my_uint32_t *);
> EOF
OK, but the return type doesn't have to be in the patched line, it could be in
a synchronization line or even missing if the function has a long multi-line argument
list.
>
> Could you try out the version of checkpatch at the URL below on the real
> patch you are using to test, and let me know if it works. There are
> a number of improvements to type tracking in the face of ifdef's and
> the like. If it doesn't could I have the hunk which fails:
>
> http://www.kernel.org/pub/linux/kernel/people/apw/checkpatch/checkpatch.pl-next
Your modified patch passes with version 0.12 as well as checkpatch.pl-next
However, the following patch that has the return type in the synchronization lines
still produces the same error:
$ ./checkpatch.pl-next -
Signed-off-by: john@smith.net
---
diff a/f.c b/f.c
--- a/f.c
+++ b/f.c
@@ -1,2 +1,4 @@
int
+foo(int a, my_uint32 *);
int
+bar(int a, my_uint32_t *);
ERROR: need consistent spacing around '*' (ctx:WxB)
#8: FILE: f.c:2:
+foo(int a, my_uint32 *);
^
total: 1 errors, 0 warnings, 4 lines checked
>
> -apw
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2008-02-11 16:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-10 14:33 bug in checkpatch (on pointers to typedefs?) Marcin Slusarz
2008-02-11 10:23 ` Andy Whitcroft
2008-02-11 16:05 ` Benny Halevy
2008-02-11 16:40 ` Andy Whitcroft
2008-02-11 16:58 ` Benny Halevy [this message]
2008-02-11 18:42 ` Andy Whitcroft
2008-02-12 8:21 ` Benny Halevy
2008-02-11 18:09 ` Marcin Slusarz
2008-02-13 19:43 ` Jan Engelhardt
2008-02-14 10:06 ` Andy Whitcroft
2008-02-14 18:29 ` Jan Engelhardt
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=47B07EA0.7010708@panasas.com \
--to=bhalevy@panasas.com \
--cc=apw@shadowen.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcin.slusarz@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.