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

[David Laight <david.laight.linux@gmail.com>]

On Mon, 12 Jan 2026 21:16:25 +0000
Al Viro <viro@zeniv.linux.org.uk> wrote:

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

I got a warning from gcc for your example (massaged a bit to compile):
<source>: In function 'f':
<source>:5:18: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
    5 |         typeof(((typeof(x)(*)(void))0)()) y;

Using __auto_type y = (1 ? 0 : 0+x) gives a non-const 'y' even with gcc 10.
The 0 seems to be needed, none of +x, -x or ~x 'lose' the constness.
Note that char/short get promoted to int - but that is hard to avoid,
and happens as soon as you use the value of a char/short variable,
?: should perform integer promotion.

I've a grep of __unqual_scalar_typeof() on my 'other monitor' (one of them)
from earlier. I'm sure most of them aren't needed at all.
arm64/..../barrier.h looks very strange - the actual accesses just depend on
the size of the item (even the union looks odd to me).

	David