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: <20190916070755.GA22009@infradead.org>
Date:   Mon, 16 Sep 2019 00:07:55 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Joe Perches <joe@...ches.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Vishal Verma <vishal.l.verma@...el.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Keith Busch <keith.busch@...el.com>,
        Ira Weiny <ira.weiny@...el.com>,
        Oliver O'Halloran <oohall@...il.com>,
        linux-kernel@...r.kernel.org,
        Dan Carpenter <dan.carpenter@...cle.com>,
        linux-nvdimm@...ts.01.org
Subject: Re: [PATCH 01/13] nvdimm: Use more typical whitespace

On Thu, Sep 12, 2019 at 08:01:45AM -0700, Joe Perches wrote:
> On Thu, 2019-09-12 at 05:17 -0700, Christoph Hellwig wrote:
> > Instead of arguing what is better just stick to what the surrounding
> > code does.
> 
> That's not always feasible nor readable.
> 
> Especially for the logic inversion blocks where
> the existing code does unreadable and error prone
> things like hiding semicolons immediately after
> comments.
> 
> 	if (foo)
> 		/* longish comment */;
> 	else {
> 		<code>;
> 	}

Which has nothing to do with your patch.

> > Or in other words:  Feel free to be a codingstyle nazi for your code
> > (I am for some of mine), but leave others peoples code alone with
> > "cleanup" patches.
> 
> My point was to avoid documenting per-subsystem
> coding style rules.

It is called common sense.  In many cases different parts of the
subsystem might have slight variations.  Just stick to your
preferred style in the bounds of coding style.  Maintainers will
either remind you if they feel strongly that they have a slightly
different preference or just fix it up.  What we really don't need
need it whitespace cleanup patches in the micro variation area.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ