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: <d187bc4bb0ff1de7812cc4d1673a55b45cb59d68.camel@HansenPartnership.com>
Date: Sun, 18 Jan 2026 14:17:30 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Steven Rostedt <rostedt@...dmis.org>, Alexey Dobriyan
 <adobriyan@...il.com>
Cc: Andy Shevchenko <andriy.shevchenko@...el.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 Sun, 2026-01-18 at 11:04 -0500, Steven Rostedt wrote:
> On Sat, 17 Jan 2026 19:23:07 +0300
> Alexey Dobriyan <adobriyan@...il.com> wrote:
> 
> > 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?
> 
> As I mentioned, for aesthetic reasons only. If code is easy to look
> at, it's easier to review. Especially for those with OCD ;-)
> 
> > 
> > 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.
> 
> I agree. I still prefer the upside-down x-mas tree approach for
> declaring variables, but obviously if they also get initialized, then
> that trumps aesthetic reasoning.

How is any of this relevant to a style document?  You're quibbling over
individual maintainer foibles which, while they may be deeply held to
you (and obviously are relevant to contributors to your subsystems
because they need to know your foibles), can't be part of our universal
advice because not all maintainers agree (not even on the direction of
the Christmas Tree).

Regards,

James