From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 69EA5207A09 for ; Tue, 13 Jan 2026 00:15:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768263330; cv=none; b=AxctWrB+86cOqu5SMH3o4pUlCNTZ8CR1tSWliXE9wzWewHPAadFwd+JLrkvVjSDbyc2sRftDBEU+2wjhHowqYHXNsd2MpM5bD0XVlfKQQKdIWBsfe5npc8Zi3RGSw8DfNwZH9qYC5ueMMQzogJJMe6Ujp5nIFQhNKi+MHkXaE8Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768263330; c=relaxed/simple; bh=bFgbnWZQw9wSzDEYIuS1d6lrUYUNDaNjYcUjSLSEC+Y=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=h/p7u5Af1A1jhp06pUwQLrdp/6qiGDs8qStcPZztEnqmbuni0bl765ThZe6zdPTpLGyKPB79o01O7KhaS7GAjCChlNYrAZ7xJYu5xGTg8ij6CUf3Dc+MXEC+aAHSLr1/915nPrhWFUEUDV9aKNPf6QmDeBpAF9Ec1YqER0wQmmw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=QSfyhtYH; arc=none smtp.client-ip=209.85.208.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QSfyhtYH" Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-64baaa754c6so10024233a12.3 for ; Mon, 12 Jan 2026 16:15:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768263327; x=1768868127; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=WNpew3LId+sbRNthjyB0JdEWExSKan52urleQaEqaao=; b=QSfyhtYHogudXxIXtvE/4H7ZxpAMocSMklKc2kLzKE4y7PWh+Bf+gfC6fXRcLSNu7c QaWWARiuY4ecpEQ88WVzbhN2MkCW78GVo06aw41q67l49ZsPb7k/0yu8M9ZXMbsvBcGY BUmnfyQsfbBF1uHhVAPNVBh89eh+FgZMpBAC9Jlb6tz9a2wPchEJZ62ph6r/ns4IZGj+ KiSG6TemUF531Ng/aTUMlHSulPh6xNW2N4lDIVoIjbaJ7LN8ba4na2xtuWSYylxxuru2 ch6QQJVsOAW33UQJa9ee6GhwWORm+vYeWlimifzNXp6G60VsFeoor7ESx55/RnATVUi6 s8WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768263327; x=1768868127; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=WNpew3LId+sbRNthjyB0JdEWExSKan52urleQaEqaao=; b=KX31QuBcXzNliiv3dQmxccJdft1Py2+zPFO7DGQbndp6Y7YC9xR+ZdMfM0UVkxJPWh 95HsbnoO5SSbF/tcE5EoAGdznHOlar+omYA4SoATC6N8WOA9tWxTunzZ/Ln1oE4KvhG+ crcLiLt9l05GpjqVB00975MAfCmIuHJ/BoMegkn16nCbas2san5Kj9wVRastvhm/4jSJ 50A8b45rxAHD/ZZk1tCzAXROl/QU5tZ53Gil0B6Q2I8t3JE19yZJ4mtENBbifPXovRGs REXJkrbmwXV/bMrJWVUXadc2Q5i29U4w41KK1XlRNeecIaGk5Wfc8xr8YEm404E6Aq4A zOqQ== X-Forwarded-Encrypted: i=1; AJvYcCUQPqck03qtLGsVMpelkXZLnIwCj49U9lIEjI/aW+IeXVjQbZi2hADlAwph9UQemwbYCfSc/cyZ5rB4Tkc=@vger.kernel.org X-Gm-Message-State: AOJu0YxMbEKs8koDPcD4dkWwrazDq9V305MFuYkD2qUMkRB0AlhFOWxR DN6XfoLvoWOlio2OAFfAuwjbTcANnOecqRAheA7s7O4h9j3/yUjRJQPY/Kbg0g== X-Gm-Gg: AY/fxX69tTaOiOl60pTjVkBYIwzU/DWmqOitSOeUOju/KdEtS9hWmQRhtMzz4y64vAQ dsW8hzdo3NTavtRnu51F4MxESa3U3RxV+v9QbqnQ8CWejgAYU6Cjhg9E86GfbCORYgNaITVZUBe kh8AKfWPmY/RbylrWierVE/Nx6Qi1dNXrzUqmCJMChfZxOpQ1tbcZMQDjTPtv2NIKleN/Q3zG3f pZD5I61MArO+lM/pkYHI+H/Sis1xQxC7Yzf/rVgvAhARMezo2Y32oQuORi9ziRAk+qj1J9kStg8 JEn2TVILNx025R/xQeOGz8x5j6ibny8kGAeIFM3PUQ2nlY9KC7m+a2m/I0J/9D5tk4cV5Y6DNmO +7K+AgAkOOKwCUhwpJAc2fFAzEufL6OYvX4Ynr2ioWxAUHQrqYMmfTCeQLJ2Q/GKsnUTaMtb6H8 iOdy3X9Z1yhNmb9oHeRxSDGPISE8H9x5IZ7CnK/de33NxVZL78Ci+R X-Google-Smtp-Source: AGHT+IE7GSDtbzTyRmgDkbP2ltmzA6dSB27mu/L7s99Fgr5xcOTDF5mka2V4i2+oXrm18D9zZurr4Q== X-Received: by 2002:a05:600c:3e8e:b0:47d:2093:649f with SMTP id 5b1f17b1804b1-47d84b187b4mr211978445e9.8.1768257564764; Mon, 12 Jan 2026 14:39:24 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f6ef885sm367288105e9.9.2026.01.12.14.39.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 14:39:24 -0800 (PST) Date: Mon, 12 Jan 2026 22:39:23 +0000 From: David Laight To: Al Viro Cc: Peter Zijlstra , Linus Torvalds , Eric Dumazet , oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org, Jakub Kicinski , Maciej =?UTF-8?B?xbtlbmN6eWtvd3NraQ==?= , Will Deacon , "Paul E. McKenney" Subject: Re: include/net/sock.h:2100:16: sparse: sparse: cast to non-scalar Message-ID: <20260112223923.78784af1@pumpkin> In-Reply-To: <20260112211625.GL3634291@ZenIV> References: <202601110443.5ENBRFej-lkp@intel.com> <20260110221508.GF3634291@ZenIV> <20260110223548.GA4041651@ZenIV> <20260111182010.GH3634291@ZenIV> <20260112123722.GJ830755@noisy.programming.kicks-ass.net> <20260112192126.GJ3634291@ZenIV> <20260112211625.GL3634291@ZenIV> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 12 Jan 2026 21:16:25 +0000 Al Viro 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): : In function 'f': :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