lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20140902151819.29c3f154@kant>
Date:	Tue, 2 Sep 2014 15:18:19 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Sander Nemvalts <snemvalts@...il.com>,
	Paul Bolle <pebolle@...cali.nl>
Cc:	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Drivers:firewire: fix style errors in core-card.c This
 is a patch in the core-card.c file which fixes up 2 warnings found by the
 checkpatch.pl tool Signed-off-by: Sander Nemvalts <snemvalts@...il.com>

Folding two replies into one.

On Sep 02 Sander Nemvalts wrote:
> On Sep 2, 2014 12:56 AM, "Stefan Richter" <stefanr@...6.in-berlin.de> wrote:
> 
> > On Sep 01 Sander Nemvalts wrote:
> > > --- a/drivers/firewire/core-card.c
> > > +++ b/drivers/firewire/core-card.c
> > > @@ -89,7 +89,8 @@ static size_t config_rom_length = 1 + 4 + 1 + 1;
> > >  #define BIB_ISC                      ((1) << 29)
> > >  #define BIB_CMC                      ((1) << 30)
> > >  #define BIB_IRMC             ((1) << 31)
> > > -#define NODE_CAPABILITIES    0x0c0083c0 /* per IEEE 1394 clause 8.3.2.6.5.2 */
> > > +/* per IEEE 1394 clause 8.3.2.6.5.2 */
> > > +#define NODE_CAPABILITIES    0x0c0083c0
> >
> > This is no improvement.
> >
> The comment after NODE_CAPABILITIES was moved to front of statement because
> the line would otherwise be over 80 characters long.

There is no problem with this line's remaining 81 characters long.

> Also, commenting before the line is demonstrated in the next statement.

This block of statements is entirely unrelated to the next statement;
furthermore the nature and form of this and the next comment are unrelated.


On Sep 02 Paul Bolle wrote:
> On Mon, 2014-09-01 at 23:56 +0200, Stefan Richter wrote:
> > On Sep 01 Sander Nemvalts wrote:
> > > @@ -132,7 +133,7 @@ static void generate_config_rom(struct fw_card *card, __be32 *config_rom)
> > >  	j = 7 + descriptor_count;
> > >  
> > >  	/* Generate root directory entries for descriptors. */
> > > -	list_for_each_entry (desc, &descriptor_list, link) {
> > > +	list_for_each_entry(desc, &descriptor_list, link) {
> > >  		if (desc->immediate > 0)
> > >  			config_rom[i++] = cpu_to_be32(desc->immediate);
> > >  		config_rom[i] = cpu_to_be32(desc->key | (j - i));
> > 
> > We are writing
> > 	for (a; b; c);
> > not
> > 	for(a; b; c);
> > and thus a space after list_for_each and friends makes sense.
> 
> $ git grep "list_for_each_entry (" | wc -l
> 52
> $ git grep "list_for_each_entry(" | wc -l
> 5991
> 
> So "list_for_each_entry(" (without space) seems to be the preferred
> style.

'Seems to be' is an appropriate wording indeed, since grep shows
occurrences, not preferences.


All,

here are some tips for whitespace changes and similar patches:

  - As a general rule, do not propose style changes to code on which you
    are not working on.

  - Do not propose style changes to code on which you are working on,
    unless you can significantly improve the code this way.

    Rationale:  Style changes (outside of drivers/staging/) tend to worsen
    rather than improve code.  Style changes obfuscate code history.  Style
    changes are of doubtfule value but create nonzero work for those who
    handle the code together with you or after you.

  - checkpatch.pl is a help for you to evaluate stylistic conformance of
    your own new code submissions.  Use checkpatch.pl for its original
    purpose.
-- 
Stefan Richter
-=====-====- =--= ---=-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ