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: <bff3cbb166dd1906c376b2465d4f2032e977c296.camel@HansenPartnership.com>
Date: Tue, 18 Nov 2025 15:28:11 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: "H. Peter Anvin" <hpa@...or.com>, ksummit@...ts.linux.dev, Dan Williams
	 <dan.j.williams@...el.com>
Cc: 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 Tue, 2025-11-18 at 11:23 -0800, H. Peter Anvin wrote:
> On 2025-11-18 08:39, James Bottomley wrote:
> > 
> > For myself I do find some value in the C89 declarations at the
> > beginning of the block for readability, so I'm happy to relax the
> > mixing rule to cases where it's strictly necessary and require
> > documenting in the comment what the necessity is.  However, I do
> > think we should, absent ordering problems, keep __free variables
> > uninitialised and at the top of the block given we can detect any
> > problem (and thus keep this rule absolutely for non-__free
> > variables where there's no ordering issues).  But, again, I'm less
> > attached to this position than I am to the consistency one: I
> > really think it's a bad idea to change the rules for one class of
> > variables but not for another, so whatever we do, we should do it
> > for everything and if that means relaxing the rule mixing code and
> > declarations for everthing, 
> > can live with that.
> > 
> 
> To me, a major win with pushing declarations down to first
> initialization or thereabouts is that it implicitly reduces the scope
> of a variable (without needing to create new blocks.)  This can
> sometimes catch some pretty serious errors.

I do somewhat agree with that.  However, I do also think it can be
clearer if you do deliberately create a scope block simply to demarcate
the variable lifetime within the code ... and if you can't do that
because of over indenting then it might be a sign the code needs to be
split up a bit more.

Regards,

James