All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@shadowen.org>
To: "Kok, Auke" <auke-jan.h.kok@intel.com>, Andrew Morton <akpm@osdl.org>
Cc: Randy Dunlap <rdunlap@xenotime.net>,
	Joel Schopp <jschopp@austin.ibm.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] update checkpatch.pl to version 0.08
Date: Tue, 24 Jul 2007 12:33:49 +0100	[thread overview]
Message-ID: <46A5E39D.7030009@shadowen.org> (raw)
In-Reply-To: <46A53F3A.7060509@intel.com>

Kok, Auke wrote:
> Andy Whitcroft wrote:
>> This version brings a number of new checks, and a number of bug
>> fixes.  Of note:
>>
>>   - warnings for multiple assignments per line
>>   - warnings for multiple declarations per line
>>   - checks for single statement blocks with braces
>>
>> This patch includes an update for feature-removal-schedule.txt to
>> better target checks.
>>
>> Andy Whitcroft (12):
>>       Version: 0.08
>>       only apply printk checks where there is a string literal
>>       allow suppression of errors for when no patch is found
>>       warn about multiple assignments
>>       warn on declaration of multiple variables
>>       check for kfree() with needless null check
>>       check for single statement braced blocks
>>       check for aggregate initialisation on the next line
>>       handle the => operator
>>       check for spaces between function name and open parenthesis
>>       move to explicit Check: entries in feature-removal-schedule.txt
>>       handle pointer attributes
> 
> within the last 3 weeks, this script went from *really usable* to *a big
> noise maker*.

She is developing for sure.  I for one don't want it to be worthless.  I
also want it to catch the things that Andrew is hottest on.  A difficult
path.  Always remember that this is a guide to style not definitive.

> I am testing this with new drivers (igb, e1000e, ixgbe) and the amount
> of warnings it throws was in the order of 10 last week, but now I'm at
> hundreds again, and my code has not changed.
> 
> The superfluous braces error should definately be fixed.

Yes, that was a misunderstanding my end, and I have loosened that check.
for the next version.  Not sure if its much use anymore but it should no
longer winge all over your patch.

> Warning on multiple declarations on a line is nice, but IMO really too
> verbose (why is "int i, j;" bad? Did C somehow change syntax today?).

No the normal response is two fold:

1) "what the heck are i and j those are meaningless names"
2) "please can we have some comments for those variables"

which normally leads to the suggestion that it be the following form:

	int source;		/* source clock hand */
	int destination;	/* destination clock hand */

and all is well.  That was the background for the checks.  However,
there is much upsetedness over it and push for i, j, k, l being a handy
form.

I am inclined to drop this check completely.  Andrew this was one of
your requests?

> Some of the new features are plain broken as I posted before. A lot of
> it now is purely false positives only.
> 
> Bottom line: I really wish that I could have the script run in the old
> behaviour before. While this level of verbosity is great for single-line
> patches, it really completely wastes my time when I'm trying to get a
> grasp for a 200k hunk piece of code.

I can only shudder at the thought of a 200k patch, but ok.

> The best way to implement this is that I can somehow select / omit some
> of these checks when running the script. With more and more checks added
> to the script it will be very quick for new driver writers to stop using
> it because of the sheer volume that the script currently outputs.

Yeah I have been feeling that we might want to say "--no-check" etc so
you can only get the more serious errors etc.  Will think on that.

-apw

  reply	other threads:[~2007-07-24 11:34 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-15  8:25 [PATCH] update checkpatch.pl to version 0.08 Andy Whitcroft
2007-07-23 23:08 ` Kok, Auke
2007-07-24  0:11   ` Randy Dunlap
2007-07-24  9:06   ` Andy Whitcroft
2007-07-24  9:15     ` Andrew Morton
2007-07-24 11:19       ` Andy Whitcroft
2007-07-24 13:08         ` Dmitry Torokhov
2007-07-24 16:51         ` Jan Engelhardt
2007-07-24 17:20           ` Randy Dunlap
2007-07-24 17:46             ` Jan Engelhardt
2007-07-24 18:03             ` Randy Dunlap
2007-07-24 18:30               ` Andy Whitcroft
2007-07-24 17:22       ` Paul Mundt
2007-07-24 18:00         ` Jan Engelhardt
2007-07-24 18:31           ` Andy Whitcroft
2007-07-24 19:49             ` Adrian Bunk
2007-07-24 20:32               ` jschopp
2007-07-25  1:13                 ` Adrian Bunk
2007-07-25 15:39                   ` SL Baur
2007-07-25 16:54                     ` Adrian Bunk
2007-07-24 18:45         ` jschopp
2007-07-24 19:59           ` Adrian Bunk
2007-07-24 20:53             ` jschopp
2007-07-23 23:13 ` Jesper Juhl
2007-07-23 23:36 ` Kok, Auke
2007-07-24 16:53   ` Jan Engelhardt
2007-07-24 17:06     ` Andy Whitcroft
2007-08-03 12:37     ` Andy Whitcroft
2007-07-23 23:52 ` Kok, Auke
2007-07-24 11:33   ` Andy Whitcroft [this message]
2007-07-24 11:47     ` Ingo Molnar
2007-07-24 11:51       ` Ingo Molnar
2007-07-24 16:56     ` Jan Engelhardt
2007-07-24 18:38       ` Andy Whitcroft
2007-07-24 13:58   ` jschopp
2007-07-24 14:33     ` Adrian Bunk
2007-07-24 14:50       ` 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=46A5E39D.7030009@shadowen.org \
    --to=apw@shadowen.org \
    --cc=akpm@osdl.org \
    --cc=auke-jan.h.kok@intel.com \
    --cc=jschopp@austin.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rdunlap@xenotime.net \
    /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.