linux-kernel - Lindent cleanup (was Re: [PATCH] drivers: Conversions from kmalloc+memset to k(z|c)alloc.)

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:	Mon, 24 Jul 2006 10:03:27 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Tomasz Kłoczko <kloczek@...y.mif.pg.gda.pl>
CC:	Michael Buesch <mb@...sch.de>, linux-kernel@...r.kernel.org,
	Alexey Dobriyan <adobriyan@...il.com>
Subject: Lindent cleanup (was Re: [PATCH] drivers: Conversions from kmalloc+memset
 to k(z|c)alloc.)

Tomasz Kłoczko wrote:
> On Mon, 24 Jul 2006, Tomasz Kłoczko wrote:
> [..]
>> In all other/most of cases (probably ~99%) Lindetd can be used .. but for NOW 
>> GENERALY IT IS NOT NOT USED.
> 
> I'm just look on number changed fles by Lindent. diffstat shows 14593 
> changed files. Number of all *.[ch] files is 16028. So it shows now 
> ~9% all files passes cleanly indentation using Lindent (my above 
> "GENERALY IT IS NOT NOT USED" isn't true :).

You already posted a good step-by-step proposal. I suggest another
slightly different approach:

People who are interested to help out should just go systematically
through subsystems and drivers, run them through Lindent, check and
perhaps beautify the output, and submit the resulting patches in a form
and to the appropriate addresses as usual (i.e. sensibly broken-up
patches, submitted to subsystem mailinglists and maintainers).

Whenever manual corrections after Lindent were necessary and whenever
there will be objections by reviewers to Lindent's results, take this
feedback as input for the two discussions about
 - consensus about preferred style, i.e. refinement of CodingStyle,
 - possible improvements of Lindent.
These discussions should of course take place at LKML instead of
subsystem mailinglists.

> IMO it is sill possible add general rule "allways use Lindent" because 
> indent can be dissabled/enabled aroud code inccorectly formated by add 
> control comments like:
> 
> /* *INDENT-OFF* */
> /* *INDENT-ON* */
> 
> If it will be widely used probably it will allow better identify some 
> indent problems.

IMHO: Write code for cpp, cc, as --- but not for any other
processor-de-jour. All those processors (formatters, checkers etc.) are
fine to *inspect* code for formal or semantic problems. But this should
not lead to thousands more or less obscure processor keywords sprinkled
all over the sources --- bloating them and making them confusing.
-- 
Stefan Richter
-=====-=-==- -=== ==---
http://arcgraph.de/sr/
-
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/