linux-kernel - Re: [PATCH RFC tip/core/rcu 2/2] rcu: Fix broken strings in RCU's source code.

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, 17 May 2012 15:32:11 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...ymtl.ca, niv@...ibm.com, tglx@...utronix.de,
	rostedt@...dmis.org, Valdis.Kletnieks@...edu, dhowells@...hat.com,
	eric.dumazet@...il.com, darren@...art.com, fweisbec@...il.com,
	patches@...aro.org
Subject: Re: [PATCH RFC tip/core/rcu 2/2] rcu: Fix broken strings in RCU's
 source code.

On Fri, May 18, 2012 at 12:20:09AM +0200, Peter Zijlstra wrote:
> On Thu, 2012-05-17 at 15:12 -0700, Paul E. McKenney wrote:
> > From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
> > 
> > Although the C language allows you to break strings across lines, doing
> > this makes it hard for people to find the Linux kernel code corresponding
> > to a given console message.  This commit therefore fixes broken strings
> > throughout RCU's source code. 
> 
> While I'm not a strict 80 chars zealot, I do find exceedingly long lines
> utterly annoying, editors either wrap them in the most hideous way or
> you don't see them.

For the most part, printable strings should have a final formatted
length of less than 80 characters so that they don't wrap in dmesg, and
preferably a bit less so that they don't wrap when prefixed with a
high-resolution timestamp.  Two main problems cause those strings to
take up more than 80 characters in source code: format specifiers that
take up more room than the parameters they format, and indentation plus
the name of the printing function.  Even keeping those in mind, lines
with strings on them shouldn't end up insanely long; if they do, perhaps
that indicates that the lines should have some newlines in the middle.

- Josh Triplett
--
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/