Jan Engelhardt wrote:
> On Jul 23 2007 16:36, Kok, Auke wrote:
>> this somehow seems to match something completely non-related (a function
>> pointer declaration case):
>>
>> ERROR: no space between function name and open parenthesis '('
>> #7278: FILE: drivers/net/e1000e/hw.h:434:
>> + bool
On Wed, Jul 25, 2007 at 08:39:36AM -0700, SL Baur wrote:
> On 7/24/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
>> There are more important things than exploiting the corner cases of
>> codingstyle, e.g. could you teach checkpatch.pl to give exactly two
>> errors for the following code?
>>
>>
>>
On 7/24/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
There are more important things than exploiting the corner cases of
codingstyle, e.g. could you teach checkpatch.pl to give exactly two
errors for the following code?
while (a);
for (b = 0; b < 50; b++);
On Tue, Jul 24, 2007 at 03:32:59PM -0500, jschopp wrote:
>>> Yep I think the consensus is we need a
>>> "--i-don't-agree-just-check-things-which-will-get-me-rejected-out-of-hand"
>>> option of some sort which will restrict output to the real errors.
>> No, the default should be to show only the rea
So, no we shouldn't separate out CodingStyle because
Better CodingStyle == less bugs
and
Better CodingStyle == more throughput for maintainers
To some extent yes.
But extreme codingstyling won't gain you anything.
Except for long and fruitless discussions.
If a tool says anything would be
Yep I think the consensus is we need a
"--i-don't-agree-just-check-things-which-will-get-me-rejected-out-of-hand"
option of some sort which will restrict output to the real errors.
No, the default should be to show only the real errors.
CodingStyle violations are real errors.
If we have agre
On Tue, Jul 24, 2007 at 01:45:25PM -0500, jschopp wrote:
>
> > checkpatch has been quite useful
>> for catching obviously broken things, and now it seems like it's just
>> overreaching. Perhaps this functionality can be split in to a lite
>> checkpatch for catching show-stoppers for application an
On Tue, Jul 24, 2007 at 07:31:35PM +0100, Andy Whitcroft wrote:
> Jan Engelhardt wrote:
> > On Jul 25 2007 02:22, Paul Mundt wrote:
> >> Perhaps CodingStyle can start being versioned, so people can opt out of
> >> certain 'improvements' whenever someone has a vision, much like some
> >> nameless li
> checkpatch has been quite useful
for catching obviously broken things, and now it seems like it's just
overreaching. Perhaps this functionality can be split in to a lite
checkpatch for catching show-stoppers for application and then something
more akin to a CodingStyle validator for the folks
Jan Engelhardt wrote:
> On Jul 24 2007 12:33, Andy Whitcroft wrote:
>>> 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 a
Jan Engelhardt wrote:
> On Jul 25 2007 02:22, Paul Mundt wrote:
>> Perhaps CodingStyle can start being versioned, so people can opt out of
>> certain 'improvements' whenever someone has a vision, much like some
>> nameless licenses.
>
> I'd say Codingstyle is versioned by means of git commit IDs.
Randy Dunlap wrote:
> On Tue, 24 Jul 2007 10:20:35 -0700 Randy Dunlap wrote:
>
>> On Tue, 24 Jul 2007 18:51:39 +0200 (CEST) Jan Engelhardt wrote:
>>
>>> On Jul 24 2007 12:19, Andy Whitcroft wrote:
>>> if (err) {
>>> do_something();
>>> return -ERR;
>>> } else {
>>>
On Jul 25 2007 02:22, Paul Mundt wrote:
>Perhaps CodingStyle can start being versioned, so people can opt out of
>certain 'improvements' whenever someone has a vision, much like some
>nameless licenses.
I'd say Codingstyle is versioned by means of git commit IDs.
>
>Personally I prefer the secon
On Tue, 24 Jul 2007 10:20:35 -0700 Randy Dunlap wrote:
> On Tue, 24 Jul 2007 18:51:39 +0200 (CEST) Jan Engelhardt wrote:
>
> >
> > On Jul 24 2007 12:19, Andy Whitcroft wrote:
> > if (err) {
> > do_something();
> > return -ERR;
> > } else {
> > do_somthing_els
On Jul 24 2007 10:20, Randy Dunlap wrote:
>> As per Ingo Molnar [ http://lkml.org/lkml/2006/9/5/68 ],
>> all blocks in an if-else 'tree' should be {} if there is at least one
>> with more than two statements. (And I do not disagree.)
>
>You are actually referring to this commit:
>
>http://git.kern
On Tue, Jul 24, 2007 at 02:15:26AM -0700, Andrew Morton wrote:
> On Tue, 24 Jul 2007 10:06:51 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
> > > This is a royal pain, since it now throws an ERROR for the obviously
> > > preferable piece of code below:
> > >
> > > if (err) {
> > > do_some
On Tue, 24 Jul 2007 18:51:39 +0200 (CEST) Jan Engelhardt wrote:
>
> On Jul 24 2007 12:19, Andy Whitcroft wrote:
> if (err) {
> do_something();
> return -ERR;
> } else {
> do_somthing_else();
> }
> >>>
> >>> if (err) {
> >>> do_something();
> >
Jan Engelhardt wrote:
> On Jul 23 2007 16:36, Kok, Auke wrote:
>> this somehow seems to match something completely non-related (a function
>> pointer declaration case):
>>
>> ERROR: no space between function name and open parenthesis '('
>> #7278: FILE: drivers/net/e1000e/hw.h:434:
>> + bool
On Jul 24 2007 12:33, Andy Whitcroft wrote:
>
>> 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"
Can
On Jul 23 2007 16:36, Kok, Auke wrote:
>
> this somehow seems to match something completely non-related (a function
> pointer declaration case):
>
> ERROR: no space between function name and open parenthesis '('
> #7278: FILE: drivers/net/e1000e/hw.h:434:
> + bool (*check_mng_mode)(struct e1
On Jul 24 2007 12:19, Andy Whitcroft wrote:
if (err) {
do_something();
return -ERR;
} else {
do_somthing_else();
}
>>>
>>> if (err) {
>>> do_something();
>>> return -ERR;
>>> } else
>>> do_something_else();
>>
>
Adrian Bunk wrote:
> On Tue, Jul 24, 2007 at 08:58:25AM -0500, jschopp wrote:
>>> within the last 3 weeks, this script went from *really usable* to *a big
>>> noise maker*.
>> As we (mostly Andy of late) add more checks (good) there is bound to be
>> some code we just didn't forsee that generates
On Tue, Jul 24, 2007 at 08:58:25AM -0500, jschopp wrote:
>> within the last 3 weeks, this script went from *really usable* to *a big
>> noise maker*.
>
> As we (mostly Andy of late) add more checks (good) there is bound to be
> some code we just didn't forsee that generates false positives (bad).
within the last 3 weeks, this script went from *really usable* to *a big
noise maker*.
As we (mostly Andy of late) add more checks (good) there is bound to be some code we just
didn't forsee that generates false positives (bad). You can see a consistent history of
cleaning these up as quickly
On 7/24/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
> On Tue, 24 Jul 2007 10:06:51 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
>>> This is a royal pain, since it now throws an ERROR for the obviously
>>> preferable piece of code below:
>>>
>>> if (err) {
>>> do_so
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> what the hell are you thinking? Not every trivial line of code needs
> to be commented. Comments are needed for the _nontrivial_ lines of
> code, and there's no way a tool can decide that. [...]
and i thought you understood this point, as earlier vers
* Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> > within the last 3 weeks, this script went from *really usable* to *a
> > big noise maker*.
seconded ...
v0.06 was "almost there". I fixed kernel/sched.c to be completely clean,
except for 3 false positives. That was a real improvement, and i sta
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 pa
Andrew Morton wrote:
> On Tue, 24 Jul 2007 10:06:51 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
>>> This is a royal pain, since it now throws an ERROR for the obviously
>>> preferable piece of code below:
>>>
>>> if (err) {
>>> do_something();
>>> return -ERR;
>>> } else {
>>> do
On Tue, 24 Jul 2007 10:06:51 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> > This is a royal pain, since it now throws an ERROR for the obviously
> > preferable piece of code below:
> >
> > if (err) {
> > do_something();
> > return -ERR;
> > } else {
> > do_somthing_else();
> > }
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
>
>
> This is bugged. e.g. the following line will hit this exception check:
>
> int i = some_function(a, b, c)
On Mon, 23 Jul 2007 16:08:26 -0700 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
>
>
> This is bugged. e.g. the following line will hit this exception check
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-remo
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-remo
On 15/07/07, Andy Whitcroft <[EMAIL PROTECTED]> 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 i
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
This is bugged. e.g. the following line will hit this exception check:
int i = some_function(a, b, c);
- warnings for multiple d
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
bet
37 matches
Mail list logo
