linux-kernel - Re: [GIT PULL] percpu fixes for 2.6.32-rc6

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]

Message-ID: <4AFBEA4B.4070100@kernel.org>
Date:	Thu, 12 Nov 2009 19:58:19 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Yinghai Lu <yhlu.kernel@...il.com>
Subject: Re: [GIT PULL] percpu fixes for 2.6.32-rc6

Hello, Ingo.

11/12/2009 07:36 PM, Ingo Molnar wrote:
> 
> * Tejun Heo <tj@...nel.org> wrote:
> 
>> Hmmm... The thing is that the nesting isn't that deep there and 
>> breaking string in the middle is something we do quite often.  What 
>> checkpatch warning did you see?
> 
> ( i did not run checkpatch over your commit - i just assumed that the 
>   ugliness was a checkpatch artifact. )
> 
> Breaking strings mid-sentence is something we try not to do. (If you 
> know about places that do it 'quite often' then those places need fixing 
> too.)

Oh... I do that all the time and I see a lot of them around too.

> the git-grep comes up empty because the string was needlessly broken in 
> mid-sentence. Which is a confusing result and which causes people to 
> waste time trying to figure out where the message came from.
> 
> The other messages in this function are fine btw, for example:
> 
>   git grep 'failed to populate'
> 
> will come up with the right place.

While I agree this is a valid reason, I really don't think we should
be restructuring whole code to accomodate long strings on single line.
I think a better way would be to teach grepping tool to match those
broken lines.  It shouldn't be too difficult to put this into ack[1]
and maybe we can have git-ack (that's a bad name for git tho).  I'll
ask ack author nicely.

> ( There are also other reasons why we dont break strings mid-sentence - 
>   it's also less readable to have it on two lines. )

This really depends on personal tastes.  When trying to use long
string literals, there are several choices.

1. Use broken strings.

				printk("blah blah blah blah "
				       "blah blah blah blah\n");

2. Push it into new line and unindent it.

				printk(
	"blah blah blah blah blah blah blah blah\n");

3. Restructure code so that the literal ends up in outer block.

	printk("blah blah blah blah blah blah blah blah\n");

I prefer the first choice.  The third would be nice if it's trivial to
do but I don't think it should dictate the code structure.  The second
one, I don't know.  Some people like that and grep will be happy with
it but it just seems very disturbing to my eyes.

Thanks.

-- 
tejun

[1] http://betterthangrep.com/
--
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/