Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 22 Sep 2016 10:49:47 -0700, Joe Perches wrote: > On Thu, 2016-09-22 at 13:57 +0200, Jean Delvare wrote: > > Sure. But I'm afraid you keep changing topics and I have no idea where > > you are going. We started with "should there be a space before jump > > labels", then out of nowhere we

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 22 Sep 2016 10:49:47 -0700, Joe Perches wrote: > On Thu, 2016-09-22 at 13:57 +0200, Jean Delvare wrote: > > Sure. But I'm afraid you keep changing topics and I have no idea where > > you are going. We started with "should there be a space before jump > > labels", then out of nowhere we

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 2016-09-22 at 13:57 +0200, Jean Delvare wrote: > Sure. But I'm afraid you keep changing topics and I have no idea where > you are going. We started with "should there be a space before jump > labels", then out of nowhere we were discussing the wording of the > output of checkpatch (how is

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 2016-09-22 at 13:57 +0200, Jean Delvare wrote: > Sure. But I'm afraid you keep changing topics and I have no idea where > you are going. We started with "should there be a space before jump > labels", then out of nowhere we were discussing the wording of the > output of checkpatch (how is

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 2016-09-22 at 14:11 +0100, Al Viro wrote: > The main intent of checkpatch these days appears to be providing an easy > way of thoughtless inflation of commit counts, everything else be damned. You've made this statement several times over many years. I don't believe it's true. I doubt

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 2016-09-22 at 14:11 +0100, Al Viro wrote: > The main intent of checkpatch these days appears to be providing an easy > way of thoughtless inflation of commit counts, everything else be damned. You've made this statement several times over many years. I don't believe it's true. I doubt

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

> > The main intent of checkpatch these days appears to be providing an easy > > way of thoughtless inflation of commit counts, everything else be damned. > > Make-work, in other words. > > Yes, I've noticed the trend too :-( But that's a problem with the > people using the tool, mostly, not with

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

> > The main intent of checkpatch these days appears to be providing an easy > > way of thoughtless inflation of commit counts, everything else be damned. > > Make-work, in other words. > > Yes, I've noticed the trend too :-( But that's a problem with the > people using the tool, mostly, not with

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 22 Sep 2016 14:11:03 +0100, Al Viro wrote: > On Thu, Sep 22, 2016 at 01:57:58PM +0200, Jean Delvare wrote: > > > > > > MUST is much stronger language than I would prefer. > > > > That's what error means, really. When your compiler fails with an > > error, you have no choice but to fix

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 22 Sep 2016 14:11:03 +0100, Al Viro wrote: > On Thu, Sep 22, 2016 at 01:57:58PM +0200, Jean Delvare wrote: > > > > > > MUST is much stronger language than I would prefer. > > > > That's what error means, really. When your compiler fails with an > > error, you have no choice but to fix

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, Sep 22, 2016 at 01:57:58PM +0200, Jean Delvare wrote: > > > > MUST is much stronger language than I would prefer. > > That's what error means, really. When your compiler fails with an > error, you have no choice but to fix your code. Warnings on the other > hand may be ignored sometimes.

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, Sep 22, 2016 at 01:57:58PM +0200, Jean Delvare wrote: > > > > MUST is much stronger language than I would prefer. > > That's what error means, really. When your compiler fails with an > error, you have no choice but to fix your code. Warnings on the other > hand may be ignored sometimes.

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 22 Sep 2016, Jean Delvare wrote: > Hi Jani, > > On Thu, 22 Sep 2016 13:43:42 +0300, Jani Nikula wrote: >> >> You could make checkpatch have different defaults for patches and files, >> to encourage better style in new code, but to discourage finding >> problems in

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 22 Sep 2016, Jean Delvare wrote: > Hi Jani, > > On Thu, 22 Sep 2016 13:43:42 +0300, Jani Nikula wrote: >> >> You could make checkpatch have different defaults for patches and files, >> to encourage better style in new code, but to discourage finding >> problems in existing code. > >

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

Hi Jani, On Thu, 22 Sep 2016 13:43:42 +0300, Jani Nikula wrote: > On Thu, 22 Sep 2016, Jean Delvare wrote: > > You need to think in terms of actual use cases. Who uses checkpatch and > > why? I think there are 3 groups of users: > > * Beginners. They won't run the script by

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

Hi Jani, On Thu, 22 Sep 2016 13:43:42 +0300, Jani Nikula wrote: > On Thu, 22 Sep 2016, Jean Delvare wrote: > > You need to think in terms of actual use cases. Who uses checkpatch and > > why? I think there are 3 groups of users: > > * Beginners. They won't run the script by themselves, instead

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 22 Sep 2016 03:42:10 -0700, Joe Perches wrote: > On Thu, 2016-09-22 at 11:24 +0200, Jean Delvare wrote: > > I would rather suggest: > > > > ERROR -> MUST_FIX > > WARNING -> SHOULD_FIX > > CHECK -> MAY_FIX > > MUST is much stronger language than I would prefer. That's what error means,

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 22 Sep 2016 03:42:10 -0700, Joe Perches wrote: > On Thu, 2016-09-22 at 11:24 +0200, Jean Delvare wrote: > > I would rather suggest: > > > > ERROR -> MUST_FIX > > WARNING -> SHOULD_FIX > > CHECK -> MAY_FIX > > MUST is much stronger language than I would prefer. That's what error means,

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 22 Sep 2016, Jean Delvare wrote: > Hi Joe, > > On Mon, 19 Sep 2016 23:32:03 -0700, Joe Perches wrote: >> On Tue, 2016-09-20 at 07:53 +0200, Julia Lawall wrote: >> > I think it is better to be clear.  CHECK was never really clear to me, >> > especially if you see it in

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 22 Sep 2016, Jean Delvare wrote: > Hi Joe, > > On Mon, 19 Sep 2016 23:32:03 -0700, Joe Perches wrote: >> On Tue, 2016-09-20 at 07:53 +0200, Julia Lawall wrote: >> > I think it is better to be clear.  CHECK was never really clear to me, >> > especially if you see it in isolation, on a file

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 2016-09-22 at 11:24 +0200, Jean Delvare wrote: [] > > The seriousness with which some beginners take these message > > types though is troublesome, [] > You need to think in terms of actual use cases. Who uses checkpatch and > why? I think there are 3 groups of users: > * Beginners. They

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 2016-09-22 at 11:24 +0200, Jean Delvare wrote: [] > > The seriousness with which some beginners take these message > > types though is troublesome, [] > You need to think in terms of actual use cases. Who uses checkpatch and > why? I think there are 3 groups of users: > * Beginners. They

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

Hi Joe, On Mon, 19 Sep 2016 23:32:03 -0700, Joe Perches wrote: > On Tue, 2016-09-20 at 07:53 +0200, Julia Lawall wrote: > > I think it is better to be clear.  CHECK was never really clear to me, > > especially if you see it in isolation, on a file that doesn't also have > > ERROR or WARNING. 

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

Hi Joe, On Mon, 19 Sep 2016 23:32:03 -0700, Joe Perches wrote: > On Tue, 2016-09-20 at 07:53 +0200, Julia Lawall wrote: > > I think it is better to be clear.  CHECK was never really clear to me, > > especially if you see it in isolation, on a file that doesn't also have > > ERROR or WARNING. 

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

On Mon, 19 Sep 2016, Joe Perches wrote: > On Tue, 2016-09-20 at 07:53 +0200, Julia Lawall wrote: > > On Mon, 19 Sep 2016, Joe Perches wrote: > > > On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > > > > IMO what we need is to go through all rules in CodingStyle and if for > > > > some rule

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

On Mon, 19 Sep 2016, Joe Perches wrote: > On Tue, 2016-09-20 at 07:53 +0200, Julia Lawall wrote: > > On Mon, 19 Sep 2016, Joe Perches wrote: > > > On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > > > > IMO what we need is to go through all rules in CodingStyle and if for > > > > some rule

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

On Tue, 2016-09-20 at 07:53 +0200, Julia Lawall wrote: > On Mon, 19 Sep 2016, Joe Perches wrote: > > On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > > > IMO what we need is to go through all rules in CodingStyle and if for > > > some rule there is no overwhelming majority in the core kernel,

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

On Tue, 2016-09-20 at 07:53 +0200, Julia Lawall wrote: > On Mon, 19 Sep 2016, Joe Perches wrote: > > On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > > > IMO what we need is to go through all rules in CodingStyle and if for > > > some rule there is no overwhelming majority in the core kernel,

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

On Mon, 19 Sep 2016, Joe Perches wrote: > On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > > IMO what we need is to go through all rules in CodingStyle and if for > > some rule there is no overwhelming majority in the core kernel, well, > > the list has grown way too large and could use

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

On Mon, 19 Sep 2016, Joe Perches wrote: > On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > > IMO what we need is to go through all rules in CodingStyle and if for > > some rule there is no overwhelming majority in the core kernel, well, > > the list has grown way too large and could use

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > IMO what we need is to go through all rules in CodingStyle and if for > some rule there is no overwhelming majority in the core kernel, well, > the list has grown way too large and could use massive trimming. I'm in complete agreement. I also

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > IMO what we need is to go through all rules in CodingStyle and if for > some rule there is no overwhelming majority in the core kernel, well, > the list has grown way too large and could use massive trimming. I'm in complete agreement. I also

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

On Mon, Sep 19, 2016 at 01:53:37PM +0200, Ilya Dryomov wrote: > > I did consider the reason to be good enough to warrant a "change", > > actually. Or more exactly from "one space is allowed" to "one space is > > recommended." Which is quite different from changing all the code > > actively. I can

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

On Mon, Sep 19, 2016 at 01:53:37PM +0200, Ilya Dryomov wrote: > > I did consider the reason to be good enough to warrant a "change", > > actually. Or more exactly from "one space is allowed" to "one space is > > recommended." Which is quite different from changing all the code > > actively. I can

Re: CodingStyle: Clarify and complete chapter 7

>>> A common type of bug to be aware of is "one err bugs" which look like this: >>> >>> -err: >>> + err: >>> kfree(foo->bar); >>> kfree(foo); >>> return ret; >>> >>> The bug in this code is that on some exit paths "foo" is NULL. Normally >>> the >> >>

Re: CodingStyle: Clarify and complete chapter 7

>>> A common type of bug to be aware of is "one err bugs" which look like this: >>> >>> -err: >>> + err: >>> kfree(foo->bar); >>> kfree(foo); >>> return ret; >>> >>> The bug in this code is that on some exit paths "foo" is NULL. Normally >>> the >> >>

Re: CodingStyle parenthesis alignment: was: Re: align to open paren

On Wed, 2015-04-15 at 21:54 +, Hubbe, Allen wrote: > I ran with the --fix option, and it changed every rejected indent to > match the column of the open paren. That's probably what you want, > since it's the most consistent with the previous behavior. The > difference is that it does not fix

RE: CodingStyle parenthesis alignment: was: Re: align to open paren

> -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: Wednesday, April 15, 2015 5:07 PM > To: Hubbe, Allen > Cc: a...@canonical.com; LKML; netdev > Subject: CodingStyle parenthesis alignment: was: Re: align to open paren > > On Wed, 2015-04-15 at 20:34 +, Hubbe,

RE: CodingStyle parenthesis alignment: was: Re: align to open paren

-Original Message- From: Joe Perches [mailto:j...@perches.com] Sent: Wednesday, April 15, 2015 5:07 PM To: Hubbe, Allen Cc: a...@canonical.com; LKML; netdev Subject: CodingStyle parenthesis alignment: was: Re: align to open paren On Wed, 2015-04-15 at 20:34 +, Hubbe, Allen

Re: CodingStyle parenthesis alignment: was: Re: align to open paren

On Wed, 2015-04-15 at 21:54 +, Hubbe, Allen wrote: I ran with the --fix option, and it changed every rejected indent to match the column of the open paren. That's probably what you want, since it's the most consistent with the previous behavior. The difference is that it does not fix

RE: CodingStyle

> -Original Message- > From: Guenter Roeck [mailto:li...@roeck-us.net] > Sent: 18 April 2013 14:42 > To: Opensource [Anthony Olech] > Cc: LKML > Subject: Re: CodingStyle > > On Thu, Apr 18, 2013 at 10:48:06AM +, Opensource [Anthony Olech] > wrote:

Re: CodingStyle

On Thu, Apr 18, 2013 at 10:48:06AM +, Opensource [Anthony Olech] wrote: > > -Original Message- > > From: Guenter Roeck [mailto:li...@roeck-us.net] > > Sent: 18 April 2013 05:14 > > To: Opensource [Anthony Olech] > > Cc: Jean Delvare; Mark Brown; Randy Dunlap; lm-sens...@lm-sensors.org;

Re: CodingStyle

On Thu, Apr 18, 2013 at 10:48:06AM +, Opensource [Anthony Olech] wrote: -Original Message- From: Guenter Roeck [mailto:li...@roeck-us.net] Sent: 18 April 2013 05:14 To: Opensource [Anthony Olech] Cc: Jean Delvare; Mark Brown; Randy Dunlap; lm-sens...@lm-sensors.org; LKML;

RE: CodingStyle

-Original Message- From: Guenter Roeck [mailto:li...@roeck-us.net] Sent: 18 April 2013 14:42 To: Opensource [Anthony Olech] Cc: LKML Subject: Re: CodingStyle On Thu, Apr 18, 2013 at 10:48:06AM +, Opensource [Anthony Olech] wrote: -Original Message- From: Guenter

Re: CodingStyle: provide good example

On Feb 5 2008 00:43, Pavel Machek wrote: >Subject: CodingStyle: provide good example > >if (!buffer) is actually prefered style, so lets use it in example. Just because it is "preferred" by some does not mean it is bad. I vote for diversity! -- To unsubscribe from this list: send the line

Re: CodingStyle: provide good example

On Tue, 5 Feb 2008 00:43:43 +0100 Pavel Machek <[EMAIL PROTECTED]> wrote: > if (!buffer) is actually prefered style, so lets use it in example. > > Pavel > > Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> > > diff --git

Re: CodingStyle: provide good example

On Tue, 5 Feb 2008 00:43:43 +0100 Pavel Machek [EMAIL PROTECTED] wrote: if (!buffer) is actually prefered style, so lets use it in example. Pavel Signed-off-by: Pavel Machek [EMAIL PROTECTED] diff --git

Re: CodingStyle: provide good example

On Feb 5 2008 00:43, Pavel Machek wrote: Subject: CodingStyle: provide good example if (!buffer) is actually prefered style, so lets use it in example. Just because it is preferred by some does not mean it is bad. I vote for diversity! -- To unsubscribe from this list: send the line unsubscribe

Re: CodingStyle: mention bitfields/whitespace style, prefer (!foo) in examples

Pavel Machek wrote: > It just would be nice to have example specifying one way... I don't see a necessity. -- Stefan Richter -=-=-=== =-=- --==- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More

Re: CodingStyle: mention bitfields/whitespace style, prefer (!foo) in examples

Pavel Machek wrote: It just would be nice to have example specifying one way... I don't see a necessity. -- Stefan Richter -=-=-=== =-=- --==- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More

Re: CodingStyle: mention bitfields/whitespace style, prefer (!foo) in examples

On Thu 2007-10-04 11:51:35, Jan Engelhardt wrote: > > On Oct 4 2007 11:44, Pavel Machek wrote: > >diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle > >index 7f1730f..1595a45 100644 > >--- a/Documentation/CodingStyle > >+++ b/Documentation/CodingStyle > >@@ -71,6 +71,15 @@ used

Re: CodingStyle: mention bitfields/whitespace style, prefer (!foo) in examples

On Oct 4 2007 11:44, Pavel Machek wrote: >diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle >index 7f1730f..1595a45 100644 >--- a/Documentation/CodingStyle >+++ b/Documentation/CodingStyle >@@ -71,6 +71,15 @@ used for indentation, and the above exam > > Get a decent editor and

Re: CodingStyle: mention bitfields/whitespace style, prefer (!foo) in examples

On Thu 2007-10-04 11:51:35, Jan Engelhardt wrote: On Oct 4 2007 11:44, Pavel Machek wrote: diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7f1730f..1595a45 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -71,6 +71,15 @@ used for

Re: CodingStyle: mention bitfields/whitespace style, prefer (!foo) in examples

On Oct 4 2007 11:44, Pavel Machek wrote: diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7f1730f..1595a45 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -71,6 +71,15 @@ used for indentation, and the above exam Get a decent editor and don't

Re: CodingStyle: start flamewar about use of braces

On 5/9/07, Stefan Richter <[EMAIL PROTECTED]> wrote: I don't know which form is better suited to the goal of well maintainable code --- the compact, easy to read, winning guideline, or the comprehensive norm. Bah, it's a slippery slope. Too little guidelines and we end up people submitting

Re: CodingStyle: start flamewar about use of braces

Satyam Sharma wrote: > It's quite funny to worship them as "prophets" and adopt their style > for some stuff (with a simple "Rationale: K") one instant and then > suggest a style completely opposite to theirs one screenful later in > the same file. That's what happens to a text which is

Re: CodingStyle: start flamewar about use of braces

Satyam Sharma wrote: It's quite funny to worship them as prophets and adopt their style for some stuff (with a simple Rationale: KR.) one instant and then suggest a style completely opposite to theirs one screenful later in the same file. That's what happens to a text which is incrementally

Re: CodingStyle: start flamewar about use of braces

On 5/9/07, Stefan Richter [EMAIL PROTECTED] wrote: I don't know which form is better suited to the goal of well maintainable code --- the compact, easy to read, winning guideline, or the comprehensive norm. Bah, it's a slippery slope. Too little guidelines and we end up people submitting code

Re: CodingStyle: start flamewar about use of braces

On 5/9/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: Randy Dunlap wrote: > On Tue, 8 May 2007 19:03:10 GMT Linux Kernel Mailing List wrote: > >> Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e659ba4a0d2d471c0d73590f78e1a1b5a1eede48 >> Commit:

Re: CodingStyle: start flamewar about use of braces

Stephen Clark wrote: Lennart Sorensen wrote: On Tue, May 08, 2007 at 05:19:45PM -0400, Jeff Garzik wrote: If anyone tries to add braces to my code's 'else' statements where they are not required, that patch will get NAK'd in a heartbeat. Oh isn't coding style fun. I personally hate code

Re: CodingStyle: start flamewar about use of braces

Lennart Sorensen wrote: On Tue, May 08, 2007 at 05:19:45PM -0400, Jeff Garzik wrote: +Do not unnecessarily use braces where a single statement will do. + +if (condition) + action(); + +This does not apply if one branch of a conditional statement is a single +statement. Use braces in

Re: CodingStyle: start flamewar about use of braces

On Tue, May 08, 2007 at 05:19:45PM -0400, Jeff Garzik wrote: > >>+Do not unnecessarily use braces where a single statement will do. > >>+ > >>+if (condition) > >>+ action(); > >>+ > >>+This does not apply if one branch of a conditional statement is a single > >>+statement. Use braces in both

Re: CodingStyle: start flamewar about use of braces

Randy Dunlap wrote: On Tue, 8 May 2007 19:03:10 GMT Linux Kernel Mailing List wrote: Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e659ba4a0d2d471c0d73590f78e1a1b5a1eede48 Commit: e659ba4a0d2d471c0d73590f78e1a1b5a1eede48 Parent:

Re: CodingStyle: start flamewar about use of braces

On Tue, 8 May 2007 19:03:10 GMT Linux Kernel Mailing List wrote: > Gitweb: > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e659ba4a0d2d471c0d73590f78e1a1b5a1eede48 > Commit: e659ba4a0d2d471c0d73590f78e1a1b5a1eede48 > Parent:

Re: CodingStyle: start flamewar about use of braces

On Tue, 8 May 2007 19:03:10 GMT Linux Kernel Mailing List wrote: Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e659ba4a0d2d471c0d73590f78e1a1b5a1eede48 Commit: e659ba4a0d2d471c0d73590f78e1a1b5a1eede48 Parent:

Re: CodingStyle: start flamewar about use of braces

Randy Dunlap wrote: On Tue, 8 May 2007 19:03:10 GMT Linux Kernel Mailing List wrote: Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e659ba4a0d2d471c0d73590f78e1a1b5a1eede48 Commit: e659ba4a0d2d471c0d73590f78e1a1b5a1eede48 Parent:

Re: CodingStyle: start flamewar about use of braces

On Tue, May 08, 2007 at 05:19:45PM -0400, Jeff Garzik wrote: +Do not unnecessarily use braces where a single statement will do. + +if (condition) + action(); + +This does not apply if one branch of a conditional statement is a single +statement. Use braces in both branches. + +if

Re: CodingStyle: start flamewar about use of braces

Lennart Sorensen wrote: On Tue, May 08, 2007 at 05:19:45PM -0400, Jeff Garzik wrote: +Do not unnecessarily use braces where a single statement will do. + +if (condition) + action(); + +This does not apply if one branch of a conditional statement is a single +statement. Use braces in

Re: CodingStyle: start flamewar about use of braces

Stephen Clark wrote: Lennart Sorensen wrote: On Tue, May 08, 2007 at 05:19:45PM -0400, Jeff Garzik wrote: If anyone tries to add braces to my code's 'else' statements where they are not required, that patch will get NAK'd in a heartbeat. Oh isn't coding style fun. I personally hate code

Re: CodingStyle: start flamewar about use of braces

On 5/9/07, Jeff Garzik [EMAIL PROTECTED] wrote: Randy Dunlap wrote: On Tue, 8 May 2007 19:03:10 GMT Linux Kernel Mailing List wrote: Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e659ba4a0d2d471c0d73590f78e1a1b5a1eede48 Commit:

Re: + codingstyle-start-flamewar-about-use-of-braces.patch added to -mm tree

On Fri, 20 Apr 2007 11:02:23 -0700 [EMAIL PROTECTED] wrote: > > The patch titled > CodingStyle: start flamewar about use of braces > has been added to the -mm tree. Its filename is > codingstyle-start-flamewar-about-use-of-braces.patch > > *** Remember to use

Re: + codingstyle-start-flamewar-about-use-of-braces.patch added to -mm tree

On Fri, 20 Apr 2007 11:02:23 -0700 [EMAIL PROTECTED] wrote: The patch titled CodingStyle: start flamewar about use of braces has been added to the -mm tree. Its filename is codingstyle-start-flamewar-about-use-of-braces.patch *** Remember to use Documentation/SubmitChecklist

Re: CodingStyle: "kzalloc()" versus "kcalloc(1,...)"

On Thu, Dec 07, 2006 at 07:16:15PM -0500, Robert P. J. Day wrote: > > i just noticed that there are numerous invocations of kcalloc() > where the hard-coded first arg of # elements is "1", which seems like > an inappropriate use of kcalloc(). > > the only rationale i can see is that

Re: CodingStyle: kzalloc() versus kcalloc(1,...)

On Thu, Dec 07, 2006 at 07:16:15PM -0500, Robert P. J. Day wrote: i just noticed that there are numerous invocations of kcalloc() where the hard-coded first arg of # elements is 1, which seems like an inappropriate use of kcalloc(). the only rationale i can see is that kcalloc()