On Fri, 27 Apr 2007, Dave Jones wrote:
> On Wed, Apr 25, 2007 at 08:02:07PM -0700, Andrew Morton wrote:
> > > Yep, I was going to mention your scripts but you beat me to it.
> > >
> > > I'll be glad to help maintain such animals if wanted.
> > >
> > wanted ;)
> >
> > At least, it would be interesting to investigate the usefulness. I suspect
> > it will prove to be very useful for the little things.
>
> Randy and I got together and hashed out a first cut at this.
> (Randy actually gutted quite a lot of what I originally wrote, so deserves
> much kudos for improving this beyond my initial crappy version).
> You can find the script at http://www.codemonkey.org.uk/projects/checkpatch/
> There's also a git clonable tree there (only http right now).
>
> http://www.codemonkey.org.uk/projects/checkpatch/example.log shows
> what fell out of running it on my mbox of lkml from the past month.
> Some of them are kinda noisy, and perhaps should be moved under --pedantic
>
> I'm all ears for additional regexps, bug reports or other suggestions.
Nice!
Here are a few more:
- Check for all of (u)int{8,16,32,64}_t
- Check for GNU extension __FUNCTION__
- Don't use space before tab
- Don't use trailing white space
Signed-off-by: Geert Uytterhoeven <[email protected]>
diff --git a/checkpatch.pl b/checkpatch.pl
index cbda29a..b44a3f3 100755
--- a/checkpatch.pl
+++ b/checkpatch.pl
@@ -143,10 +143,26 @@ sub process {
"Bad variable name: tmp. Please use something more descriptive.\n");
$warnings += search(qr/temp(,|;)/,
"Bad variable name: temp. Please use something more descriptive.\n");
+ $warnings += search(qr/uint8_t/,
+ "Incorrect type usage for kernel code. Use __u8/u8\n");
+ $warnings += search(qr/uint16_t/,
+ "Incorrect type usage for kernel code. Use __u16/u16\n");
$warnings += search(qr/uint32_t/,
- "Incorrect type usage for kernel code. Use __u32 etc.\n");
+ "Incorrect type usage for kernel code. Use __u32/u32\n");
+ $warnings += search(qr/uint64_t/,
+ "Incorrect type usage for kernel code. Use __u64/u64\n");
+ $warnings += search(qr/int8_t/,
+ "Incorrect type usage for kernel code. Use __s8/s8\n");
+ $warnings += search(qr/int16_t/,
+ "Incorrect type usage for kernel code. Use __s16/s16\n");
+ $warnings += search(qr/int32_t/,
+ "Incorrect type usage for kernel code. Use __s32/s32\n");
+ $warnings += search(qr/int64_t/,
+ "Incorrect type usage for kernel code. Use __s64/s64\n");
$warnings += search(qr/\b(BUG|BUG_ON)\b/,
"Try to use WARN_ON & Recovery code rather than BUG() or BUG_ON()\n");
+ $warnings += search(qr/__FUNCION__/,
+ "Should use C99 __func__ instead of GNU __FUNCTION__\n");
}
# coding style:
@@ -154,6 +170,8 @@ sub process {
$warnings += search(qr/,[^[:space:]]/, "Need space after comma:\n");
$warnings += search(qr/\([[:space:]]/, "Don't use space after '(':\n");
$warnings += search(qr/[[:space:]]\)/, "Don't use space before ')':\n");
+ $warnings += search(qr/ \t/, "Don't use space before tab:\n");
+ $warnings += search(qr/[[:space:]]$/, "Don't use trailing white space:\n");
$warnings += search(qr/if\(|for\(|while\(|switch\(/,
"Need space after if/for/while/switch:\n");
$warnings += search(qr/sizeof[[:space:]]/,
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[email protected] ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
On Wed, May 02, 2007 at 04:28:27PM +0200, Geert Uytterhoeven wrote:
> - Check for GNU extension __FUNCTION__
__FUNCTION__ is prefered over __func__
On Wed, 2 May 2007, Christoph Hellwig wrote:
> On Wed, May 02, 2007 at 04:28:27PM +0200, Geert Uytterhoeven wrote:
> > - Check for GNU extension __FUNCTION__
>
> __FUNCTION__ is prefered over __func__
Is there a reason for that?
- __FUNCTION__ is a GNU extension
- __func__ is C99
- __func__ is shorter to type ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[email protected] ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
On May 2 2007 16:28, Geert Uytterhoeven wrote:
> - Check for all of (u)int{8,16,32,64}_t
I strongly disagree. These should be allowed, for they are (I think) C99.
Jan
--
On May 2 2007 16:29, Christoph Hellwig wrote:
>On Wed, May 02, 2007 at 04:28:27PM +0200, Geert Uytterhoeven wrote:
>> - Check for GNU extension __FUNCTION__
>
>__FUNCTION__ is prefered over __func__
`info gcc` tells:
`__FUNCTION__' is another name for `__func__'. Older versions of GCC
recognize only this name. However, it is not standardized. For
maximum portability, we recommend you use `__func__', but provide a
fallback definition with the preprocessor:[...]
Jan
--
On Wed, 2 May 2007 17:32:49 +0200 (CEST)
Geert Uytterhoeven <[email protected]> wrote:
> On Wed, 2 May 2007, Christoph Hellwig wrote:
> > On Wed, May 02, 2007 at 04:28:27PM +0200, Geert Uytterhoeven wrote:
> > > - Check for GNU extension __FUNCTION__
> >
> > __FUNCTION__ is prefered over __func__
>
> Is there a reason for that?
> - __FUNCTION__ is a GNU extension
> - __func__ is C99
> - __func__ is shorter to type ;-)
>
In that case we should use __func__.
But we discussed this at some length 3-4 years ago and decided to use
__FUNCTION__. I don't remember why. Perhaps problems with gcc support for
__func__?
(It could have been that compile-time string concatenation was involved:
printf("xxx" __FILE__); /* works */
printf("xxx" __FUNCTION__); /* doesn't */
Or not.)
On Wed, 2 May 2007, Andrew Morton wrote:
> On Wed, 2 May 2007 17:32:49 +0200 (CEST)
> Geert Uytterhoeven <[email protected]> wrote:
>
> > On Wed, 2 May 2007, Christoph Hellwig wrote:
> > > On Wed, May 02, 2007 at 04:28:27PM +0200, Geert Uytterhoeven wrote:
> > > > - Check for GNU extension __FUNCTION__
> > >
> > > __FUNCTION__ is prefered over __func__
> >
> > Is there a reason for that?
> > - __FUNCTION__ is a GNU extension
> > - __func__ is C99
> > - __func__ is shorter to type ;-)
> >
>
> In that case we should use __func__.
>
> But we discussed this at some length 3-4 years ago and decided to use
> __FUNCTION__. I don't remember why. Perhaps problems with gcc support for
> __func__?
I tried gcc 2.95/3.2/3.3/3.4/4.0/4.1, they all recognize __func__ and
__FUNCTION__, like in e.g. printf("%s", __func__);
> (It could have been that compile-time string concatenation was involved:
>
>
> printf("xxx" __FILE__); /* works */
> printf("xxx" __FUNCTION__); /* doesn't */
>
> Or not.)
Yep, when trying concatenation, I got:
- 2.95: works fine
- 3.2:
syntax error before "__func__"
warning: concatenation of string literals with __FUNCTION__ is deprecated
- 3.3:
error: syntax error before "__func__"
warning: concatenation of string literals with __FUNCTION__ is deprecated
- 3.4/4.0:
error: syntax error before "__func__"
error: syntax error before "__FUNCTION__"
- 4.1:
error: expected ')' before '__func__'
error: expected ')' before '__FUNCTION__'
Hence gcc 3.2 and up treat __func__ like the a variable, as per C99, while
__FUNCTION__ has been moving from a virtual preprocessor definition in 2.95 to
a variable, like __func__.
So in the end it doesn't matter, as concatenation has been fixed in the Linux
source tree anyway.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[email protected] ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
On Wed, 2 May 2007 21:55:16 +0200 (CEST)
Geert Uytterhoeven <[email protected]> wrote:
> On Wed, 2 May 2007, Andrew Morton wrote:
> > On Wed, 2 May 2007 17:32:49 +0200 (CEST)
> > Geert Uytterhoeven <[email protected]> wrote:
> >
> > > On Wed, 2 May 2007, Christoph Hellwig wrote:
> > > > On Wed, May 02, 2007 at 04:28:27PM +0200, Geert Uytterhoeven wrote:
> > > > > - Check for GNU extension __FUNCTION__
> > > >
> > > > __FUNCTION__ is prefered over __func__
> > >
> > > Is there a reason for that?
> > > - __FUNCTION__ is a GNU extension
> > > - __func__ is C99
> > > - __func__ is shorter to type ;-)
> > >
> >
> > In that case we should use __func__.
> >
> > But we discussed this at some length 3-4 years ago and decided to use
> > __FUNCTION__. I don't remember why. Perhaps problems with gcc support for
> > __func__?
>
> I tried gcc 2.95/3.2/3.3/3.4/4.0/4.1, they all recognize __func__ and
> __FUNCTION__, like in e.g. printf("%s", __func__);
>
> > (It could have been that compile-time string concatenation was involved:
> >
> >
> > printf("xxx" __FILE__); /* works */
> > printf("xxx" __FUNCTION__); /* doesn't */
> >
> > Or not.)
>
> Yep, when trying concatenation, I got:
> - 2.95: works fine
> - 3.2:
> syntax error before "__func__"
> warning: concatenation of string literals with __FUNCTION__ is deprecated
> - 3.3:
> error: syntax error before "__func__"
> warning: concatenation of string literals with __FUNCTION__ is deprecated
> - 3.4/4.0:
> error: syntax error before "__func__"
> error: syntax error before "__FUNCTION__"
> - 4.1:
> error: expected ')' before '__func__'
> error: expected ')' before '__FUNCTION__'
>
> Hence gcc 3.2 and up treat __func__ like the a variable, as per C99, while
> __FUNCTION__ has been moving from a virtual preprocessor definition in 2.95 to
> a variable, like __func__.
>
> So in the end it doesn't matter, as concatenation has been fixed in the Linux
> source tree anyway.
>
Great, thanks for working all that out.
So __func__ it is. In new code. However "convert __FUNCTION__ to
__func__" patches will be cheerfully ignored - life is too short.
err, kernel.h has
/* Trap pasters of __FUNCTION__ at compile-time */
#define __FUNCTION__ (__func__)
On Wed, 2 May 2007 16:28:27 +0200 (CEST) Geert Uytterhoeven <[email protected]> wrote:
> + $warnings += search(qr/__FUNCION__/,
^__FUNCTION__ maybe?
> + "Should use C99 __func__ instead of GNU __FUNCTION__\n");
S?bastien.
On Thu, 3 May 2007, [ISO-8859-1] S?bastien Dugu? wrote:
> On Wed, 2 May 2007 16:28:27 +0200 (CEST) Geert Uytterhoeven <[email protected]> wrote:
>
>
> > + $warnings += search(qr/__FUNCION__/,
>
> ^__FUNCTION__ maybe?
>
> > + "Should use C99 __func__ instead of GNU __FUNCTION__\n");
Bummer... Of course!
Thx!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[email protected] ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium