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
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 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 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?
while
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
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
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
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
> 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
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
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 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:
>
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) {
> > >
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"
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
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
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
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
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) {
>>>
* 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
* 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
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
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 {
>>>
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,
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);
Yep that
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();
}
Hmmm, is that
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_somthing_else();
}
Hmmm,
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
* 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 started
* 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 versions
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_something();
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
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). You
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 false
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();
The kool kids on linux-usb-devel largely
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 e1000_hw
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 we at least
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 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();
return -ERR;
} else
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_something();
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:
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_else();
}
if (err) {
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 second
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 {
do_somthing_else();
}
if (err) {
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.
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 are meaningless
snip
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
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 licenses.
On Tue, Jul 24, 2007 at 01:45:25PM -0500, jschopp wrote:
snip
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
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
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
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 real errors.
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
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
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
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
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
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
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
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
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
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:
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
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
74 matches
Mail list logo
