linux-kernel - RE: Clarifying confusion of our variable placement rules caused by cleanup.h

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:
 <PH0PR13MB5639535AC3D1232831FD2380FD8AA@PH0PR13MB5639.namprd13.prod.outlook.com>
Date: Sat, 17 Jan 2026 16:54:43 +0000
From: "Bird, Tim" <Tim.Bird@...y.com>
To: Alexey Dobriyan <adobriyan@...il.com>,
        Steven Rostedt
	<rostedt@...dmis.org>
CC: Andy Shevchenko <andriy.shevchenko@...el.com>,
        James Bottomley
	<James.Bottomley@...senpartnership.com>,
        "ksummit@...ts.linux.dev"
	<ksummit@...ts.linux.dev>,
        Dan Williams <dan.j.williams@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Dan Carpenter
	<dan.carpenter@...aro.org>
Subject: RE: Clarifying confusion of our variable placement rules caused by
 cleanup.h

> -----Original Message-----
> From: Alexey Dobriyan <adobriyan@...il.com>
> 
> On Fri, Jan 02, 2026 at 09:50:29AM -0500, Steven Rostedt wrote:
> > On Wed, 31 Dec 2025 13:17:32 +0100
> > Andy Shevchenko <andriy.shevchenko@...el.com> wrote:
> >
> > > > There was variation of this type of nonsense with headers (not only it has
> > > > to be sorted alphabetically but by length too!)
> > >
> > > By length it indeed sounds weird, but alphabetical is the natural language
> > > order everybody learnt from the daycare / school years, so it's properly
> > > programmed in our deep brain. Having that allows to find easily if anything one
> > > is interested in is already being included. Also it allows to avoid dup inclusions
> > > (was there, fixed that for real). So, it's not bad.
> >
> > Actually, I like the "by length" because its aesthetically easier on the eyes.
> >
> > Alphabetically is fine, but either one helps in catching duplicate headers.
> 
> Such rules for headers are mostly harmless -- headers are supposed to be
> idempotent so ordering doesn't matter. But if ordering doesn't matter
> why have a rule at all?
The rule is (or at least was, at one point) helpful to reduce the likelihood
merge conflicts during patch application.  I know patch and quilt still
don't ignore mismatched #include lines in the patch context, even
though #include lines in C are independent of each other.  I'm not sure if git
handles this better or not.

When everyone appends new #include lines at the end of the block of lines,
there is more likelihood of a patch conflict right there.  If the #include lines
are instead sorted in some fashion, it reduces (but obviously does not eliminate)
the possibility of a patch conflict.
 -- Tim