netdev - Re: [PATCH] Keep kernel coding style rule of hfs-s+/sp source

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] [day] [month] [year] [list]

Message-Id: <20120201.020602.131240058939599710.davem@davemloft.net>
Date:	Wed, 01 Feb 2012 02:06:02 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	geunsik.lim@...il.com
Cc:	isdn@...ux-pingi.de, lucas.demarchi@...fusion.mobi,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Keep kernel coding style rule of hfs-s+/sp source

From: Geunsik Lim <geunsik.lim@...il.com>
Date: Wed,  1 Feb 2012 15:59:53 +0900

> Modified for kernel coding style rule of hfs-s+/sp device driver .
> . reference: ./Documentation/CodingStyle
> 
> ex)
> 60 Don't put multiple statements on a single line unless you have
> 61 something to hide:
> 62
> 63         if (condition) do_this;
> 64           do_something_everytime;
> 
> Signed-off-by: Geunsik Lim <geunsik.lim@...sung.com>

This was probably there to eliminate compiler warnings or avoid the
code being eliminated completely, because the result of the register
read is unused.

Have you verified that neither is the case here?

To be honest I very strongly dislike patches like this.  You're
patching a driver that very few people use, and changes like this can
only risk possible regressions that will be hard to notice and it's
not like people scour over this driver often and thus will be upset by
frequently seeing some minor coding style infraction.

I'm not applying this patch.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html