linux-kernel - Re: include/net/sock.h:2100:16: sparse: sparse: cast to non-scalar

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: <20260112211625.GL3634291@ZenIV>
Date: Mon, 12 Jan 2026 21:16:25 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	Eric Dumazet <edumazet@...gle.com>, oe-kbuild-all@...ts.linux.dev,
	linux-kernel@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
	Maciej Żenczykowski <maze@...gle.com>,
	Will Deacon <will@...nel.org>,
	"Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: include/net/sock.h:2100:16: sparse: sparse: cast to non-scalar

On Mon, Jan 12, 2026 at 07:21:26PM +0000, Al Viro wrote:
> On Mon, Jan 12, 2026 at 01:37:22PM +0100, Peter Zijlstra wrote:
> 
> > > #define unqual_non_array(T) __typeof__(((T(*)(void))0)())
> > > 
> > > would do the right thing without that _Generic cascade and it'll work
> > > just fine for e.g. kuid_t.  Using it for an array would trigger an error,
> > > array-returning functions being forbidden...
> > > 
> > > Guys, do you have any problems with replacing __unqual_scalar_typeof()
> > > uses with that thing?
> > 
> > There is also __typeof_unqual__, but I do not know if that is now
> > supported by all compilers, if so that is the better option. If not,
> > your function return type thing is awesome.
> 
> >From experimenting with godbolt.org:
> 			clang		gcc		icc
> __typeof_unqual__	>= 19.0.1	>= 14.1		no
> this trick		>= 3.0.0	>= 8.4		>= 13.0.1
> our minima		15.0.0		8.1
> 
> So __typeof_unqual__ is well out of our range; this trick is slightly
> out of range, but nowhere near as bad.  Prior to 8.4 gcc had a bug
> in that area, unfortunately ;-/
> 
> Might make sense to reconsider it next time we bump gcc minimum...

Speaking of fun gcc bugs: prior to 11.1 gcc would not strip qualifiers
in conditional operator; I hadn't tried to RTFS, but it almost looks like
they took the union of qualifiers on the second and the third arguments
of ?:

That's a direct violation of standard, all way back to C90 - the type
of 0 ? x : x where x is an l-value of qualified type *is* explicitly
required to be the unqualified version of that type; C90#6.2.2.1 does
list the contexts where l-value is not converted to non-l-value and ?:
arguments are not among those, with clearly stated requirement to strip
qualifiers when converting to non-l-value.

Once upon a time gcc used to have a weird extension that made (a ? b : c)
an l-value if both b and c had been, which might explain the origin of
that bug, but that went further - even in cases like
	const int x;
	__typeof__(0 ? x : 1) y;
they ended with const leaking to y, which would be a bug even in C++,
where that extension for ?: originated (prvalue int as the third argument
ends up with lvalue-to-rvalue conversions applied to the second one,
stripping any qualifiers from it)...