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: <38d7b19f-b6ff-437b-bc88-fa2047ca556a@p183>
Date: Sat, 17 Jan 2026 19:23:07 +0300
From: Alexey Dobriyan <adobriyan@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	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

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?

Duplicate header are trivially caught by tooling.

But such rules aren't useful either -- I've seen that Python IDEs hide
import list by default (and probably manage it) because it is not "real"
code.

Rules for initializers can be harmful because ordering affects code
generation.