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

[Al Viro <viro@zeniv.linux.org.uk>]

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)...