linux-kernel - Re: emacs and "linux" 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: <0A4C5074-D482-42EE-98D1-93C636BC80B8@mit.edu>
Date:	Wed, 14 Jul 2010 02:12:13 -0400
From:	Theodore Tso <tytso@....EDU>
To:	Randy Dunlap <rdunlap@...otime.net>
Cc:	Dimitrios Apostolou <jimis@....net>, linux-kernel@...r.kernel.org,
	Dan Nicolaescu <dann@....org>
Subject: Re: emacs and "linux" coding style

On Jul 13, 2010, at 6:19 PM, Randy Dunlap wrote:
> 
> See CodingStyle, Chapter 1, Indentation:
> 
> "Outside of comments, documentation and except in Kconfig, spaces are never
> used for indentation, and the above example is deliberately broken."
> 
> which to me means "spaces alone are never used (unless the indentation is less than
> 8 columns)".

There is a huge amount of code --- including code which I submitted
back in the 0.12 days of Linux --- which uses spaces to align continuation
lines for function parameters, i.e.

static int foo(struct inode inode, struct file *file, int flags,
		       size_t len)

such that "struct" and "size_t" are aligned on the same column, and also so that:

	unsigned int num = ((len + sizeof(struct foobaz) - 3) /
					     (4 + sizeof(struct foobaz)));

I've always read indentation as referring to indentation for the beginning of
code lines, but not to making function parameters or paraenthesis line
up.   This is something which emacs does automatically, but vi does not.

People who are anal enough to worry about this sort of thing, in general,
IMHO, really should find better things to do.   And if checkpatch.pl were to
be "improved" to start issue warnings about code not adhering to this 
CodingStyle assertion, #1, you would find out how much code doesn't 
adhere to this, and #2, I think a lot of people, including myself, would be
complaining vociferously and agitating to have that language removed
from CodingStyle as being an actively harmful and incorrect recommendation.

-- Ted

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