linux-kernel - Re: coding style

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: <alpine.LFD.0.98.0706160840290.14121@woody.linux-foundation.org>
Date:	Sat, 16 Jun 2007 08:49:55 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jan Engelhardt <jengelh@...putergmbh.de>
cc:	Cyrill Gorcunov <gorcunov@...il.com>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Chris Friesen <cfriesen@...tel.com>,
	dave young <hidave.darkstar@...il.com>,
	Willy Tarreau <w@....eu>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: coding style

On Sat, 16 Jun 2007, Jan Engelhardt wrote:
> >
> >Heh. Actually, Linux maintainers have generally very consciously _avoided_ 
> >trying to "enforce" coding style issues.
> 
> Really? "it's not going to be merged unless you turn all uint32_t into
> u_int32_t" is a paraphrased variant of what I was told this month.

I suspect different maintainers are hung up on different things, so yes, 
certain things are more likely to carry red flags, and it also depends on 
the patch.

For example, if I get a patch for something that is a whole driver, I 
generally think that while I *prefer* to see it follow the kernel coding 
style, I also expect that the person who sends me the driver is the one 
who is going to maintain it in the future, and thus his personal coding 
style preferences will override any but the strongest objections.

(So if somebody sends me a FSF-style "tabs are two characters, and 
functions must be longer than 300 lines" mess, I generally would prefer to 
not take it at all, but for some really obscure driver I might not care).

In contrast, if a patch modifies code that somebody else really will end 
up touching in the future (maybe not "maintain", but maybe there is no 
single and obvious maintainer), it had better match the code around it.

So to take your particular example: For me, "uint32_t" is certainly better 
than "u_int32_t" (and there's seven times as many of the former as the 
latter in the kernel), but for code _I_ would touch, I'd actually prefer 
the Linux internal "__u32"/"u32", which have no question about what their 
user-space visibility is (ie "__u32" is *always* ok in a header file that 
is visible to user space).

But would I make it a huge issue? Not personally. So it will depend on the 
maintainer.

(Personally, I think the "small functions, no deep levels of indentation, 
and tabs are 8 characters wide" are the most important part by far. But I 
do actually end up complaining about function naming etc too).

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