linux-kernel - Re: [PATCH] teach checkpatch.pl about list_for

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Jan 2008 11:10:58 +0000
From:	Andy Whitcroft <andyw@...ibm.com>
To:	Christer Weinigel <christer@...nigel.se>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] teach checkpatch.pl about list_for_each

On Sun, Dec 02, 2007 at 01:03:35PM +0100, Christer Weinigel wrote:
> Hi Andy,
> 
> you seem to be the last person messing around with checkpatch.pl so I'm
> addressing this to you. :-)
> 
> checkpatch complains about the following:
> 
> WARNING: no space between function name and open parenthesis '('
> #520: FILE: drivers/spi/spi_s3c24xx_dma.c:478:
> +       list_for_each_entry (transfer, &message->transfers, transfer_list) {
> 
> which I think is a bit bogus since it actually is a for statement in
> disguise.  The following patch adds list_for_each to the list of things
> that look like functions that it shouldn't complain about.

We have had some stabs at changing this, but no consensus was reached on
whether it was a "for" or a "function".  My memory is of there being
slightly more "without a space" tenders than the other and so it has not
been changed.  This thread also seems so far to have not really
generated a concensus.  So I would tend to leave things as they are.  

A third option might be to accept either on *for_each* constructs.
That might tend to lead to divergance.  Difficult.  However, also see my
later comments on "style guide".

> 
> By the way, what is the consensus on lines over 80 characters?
> checkpatch complains about the following:
> 
> WARNING: line over 80 characters
> #762: FILE: drivers/spi/spi_s3c24xx_dma.c:720:
> +       printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav Technologies AB\n");
> 
> I can of course break this into:
> 
>         printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav "
> 	       "Technologies AB\n");
> 
> but in my opinion that becomes more even unreadable.  Would it be
> possible to add a special case so that checkpatch ignores long strings
> that go beyond 80 characters?  Do you think it is a good idea?

I think you are miss-understanding the point of checkpatch here.  It has
flagged this line as suspect.  You are happy it is better as it is.  You
should therefore leave it as it is as you "are happy to justify that
checkpatch failure".  Checkpatch is a style guide, if it complains you
should think about its complaint and act as you see fit in response.
Sometimes you will ignore it, that is fine.

-apw
--
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/