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: <1491918610.7236.12.camel@kernel.crashing.org>
Date:   Tue, 11 Apr 2017 23:50:10 +1000
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        netdev@...r.kernel.org
Subject: Re: [PATCH 01/10] ftgmac100: Upgrade to NETIF_F_HW_CSUM

On Tue, 2017-04-11 at 21:13 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 13:57 +0300, Sergei Shtylyov wrote:
> >     Need {} here as well since the 1st branch has it -- see 
> > Documentation/process/coding-style.rst (the end of the section 3).
> 
> Adding {} in that specific statements just makes things more
> cluttered and less readable.
> 
> I can find a ton of examples of 
> 
> 	if (...) {
> 		multi lines
> 		...
> 	} else if (...)
> 		single_line()
> 
> In existing kernel code.
> 
> I'll fix it in a next spin if Dave wants it that way but otherwise
> I'm keen to leave it as it is.

I actually took the time to read the coding-style.txt statement,
and I would argue that it is about

	if (...) {
		...
	} else {
		...
	}

Which is a different can of worms. I tend to agree that the else by
itself followed by a single tabulated statement is a bit "odd" and
I tend to use braces in that case as well.

However the "} else if (...)" case is subtly different and from a code
clarity point of view I prefer what I wrote.

This isn't an accident, I specifically wrote that statement that way
because I preferred how the code looked like that way.

This tend to be my problem with coding style rules (and people who
comment on patches solely on coding style issues, especially so
marginal ones ;-) ... this needs to be applied along with a bit of
common sense and taste.

Those rules should be "general guidelines" not absolute laws. A
specific piece of code might benefit from violating some of them
occasionally for all sort of reasons provided the end result is both
clear and more concise for example.

Anyway, way too much internet bandwidth wasted today on that subject.

Dave, just let me know how you want it to look like :-)

Cheers,
Ben.
  

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ