linux-kernel - Re: [PATCH] update checkpatch.pl to version 0.06

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: <467C1233.5030609@austin.ibm.com>
Date:	Fri, 22 Jun 2007 13:17:23 -0500
From:	Joel Schopp <jschopp@...tin.ibm.com>
To:	Dave Hansen <hansendc@...ibm.com>
CC:	Andy Whitcroft <apw@...dowen.org>, Andrew Morton <akpm@...l.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] update checkpatch.pl to version 0.06

> Several of our on-disk filesystems have an ioctl function that already
> has indented goto labels.  I don't think it's quite worth churning all
> of these (working) filesystems to make a style checker happy.
> 
> I think it's worse style to be mixing label indentation in a file as it
> is to create new "correct" indentation labels.  That's why I suggested
> using context in the file to determine it rather than absolute rules.

If it is bad coding style that is justified because there is already other bad coding 
style to match -- that is not a judgment call for a script to make, but for a real 
person to make.

There is no law that says you have to fix 100% of the warnings the script generates, 
even if they are valid warnings.  You'd just better be ready to justify them is all. 
  Your justification seems reasonable in this case -- it is worse to mix right and 
wrong label indentation vs indenting wrongly but consistently.

Indent consistently wrong and feel happy about it, just don't expect the style 
checker to give you a free pass when you perpetuate somebody else's wrong.  If we 
start down the path of bad coding style always being OK if there is already bad 
coding style around it I think that is a slippery slope.  There should be some 
friction when we perpetuate bad style so there is some incentive to fix the style for 
future generations to be able to read our code better.

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