linux-kernel - Re: [PATCH next] minmax.h: Use auto for variables in __minmax

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: <20260208113357.62e769b8@pumpkin>
Date: Sun, 8 Feb 2026 11:33:57 +0000
From: David Laight <david.laight.linux@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Peter Anvin <hpa@...or.com>, Andy Shevchenko
 <andriy.shevchenko@...ux.intel.com>, Arnd Bergmann <arnd@...nel.org>,
 Christoph Hellwig <hch@...radead.org>, "Jason A . Donenfeld"
 <Jason@...c4.com>, Herve Codina <herve.codina@...tlin.com>, Linus Torvalds
 <torvalds@...ux-foundation.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH next] minmax.h: Use auto for variables in
 __minmax_array()

On Sat, 7 Feb 2026 18:25:59 -0800
Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Sat, 7 Feb 2026 10:25:51 +0000 David Laight <david.laight.linux@...il.com> wrote:
> 
> > On Fri, 6 Feb 2026 14:41:35 -0800
> > Andrew Morton <akpm@...ux-foundation.org> wrote:
> >   
> > > On Fri,  6 Feb 2026 22:25:54 +0000 david.laight.linux@...il.com wrote:
> > >   
> > > > From: David Laight <david.laight.linux@...il.com>
> > > > 
> > > > While 'auto __element = _array[--__len]' should remove 'const',
> > > > gcc prior to version 11 are buggy and retain it.    
> > > 
> > > With what effect?  
> > 
> > If you have:
> > int f(const int x)
> > {
> > 	auto y = x;
> > 	y++;
> > 	return y;
> > }
> > gcc prior to 11.0 error that y is const.
> > So in this case the loop can't change __element.  
> 
> Still not undersanding, sorry.  Does this patch fix a build issue with
> any compiler/kernel combination?
> 
> > > I'm not understanding the motivation for this change.  Is there some
> > > compilation issue to be addressed?  
> > 
> > Mainly unqual_scalar_typeof() being horrid.
> > There is an ongoing long thread about its use in the arm64 LTO READ_ONCE().
> > Newer compilers do have a builtin, and there are some shorter alternatives
> > that work in some places.
> > But here is just isn't needed.
> > So one less place to check.  
> 
> OK, so it's a cleanup.
> 
> > I did mean to copy the main contributers to that thread, but forgot.  
> 
> I think a v2 would be good please, to clarify the effects of and
> motivation for the change.

Ok - I always expect to do a v2, the way of the world.

	David