From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F403682D99 for ; Tue, 23 Jan 2024 20:19:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706041158; cv=none; b=n0aJnQzE7PugcDTp7RPiPyhVpVlKFZqO/L+wb4bOjwifYfqrX4WEkyHbbNbxutnGP3scHcVmP2zpD3gdDkME6a0+ol/cKcozjONY9sw5HMC5hCr5RW97O2p+RxIanpEAi2rl4bEggX086zjNYPtTkdQVZps/z3rr/KzM0RbRnfg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706041158; c=relaxed/simple; bh=xEm9wsqcZ1AbcRSFX9+1//LvUgCwaeHQsT/YVOII2GE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bC7SHBQjXYMGA72i//K/k7kj1ZAXTtihwO4fTKhvaL4gHYAkQitqYFojKMNGyypdKiFTIKMyp7pNmGPE1qMVKo5m7Z45alJGxVq7NkMpZjP50h1AXgmuki6g9EHOWZMzrYKRfuA2hdmICKmjMNZPGM2ETmIlG+6YFd9yGeKt9iU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=iGgx/c7w; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="iGgx/c7w" Received: from [IPV6:2601:646:8002:4640:7285:c2ff:fefb:fd4] ([IPv6:2601:646:8002:4640:7285:c2ff:fefb:fd4]) (authenticated bits=0) by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 40NKGhOB3259866 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 23 Jan 2024 12:16:43 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 40NKGhOB3259866 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2024011201; t=1706041004; bh=IMpXzzNvb+XGglRNXDzMvK5C4yvMG5YVXjVxTlAF02U=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=iGgx/c7w5T2DB0FA6yYqTy7SBz5t2ULa1umqNzLv/m/4PEeBup3tv436DXjE2cDUi EocSXPjO5EBd1OPSIrA4W/sM1U+Bts87rETusgAhE48I+j0lWAuvG4fbAbSMLWbjB9 0W7PCpN9ZRzb6ajxlmFt81tkHv/rWt50Q87UZTVGxdQLXbYAeICwkgC7s1eBMmlDZ9 /SbwBJjh0dACi692ELw4wapArD3cv3/MdEj+V1LYpdjW3+sxnIewYWiw9EBKFI2ncS oZvU6GzlEKXZnTWrt2ls3AoCO7t6J2hIwEaisgBMquPBI+5S9o8bRMiL1+ACTGu6/s MgBRPMWe+UXeQ== Message-ID: <57324f9b-c851-4120-82b6-dbbf21cb2720@zytor.com> Date: Tue, 23 Jan 2024 12:16:37 -0800 Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: A few proposals from the C standards committee Content-Language: en-US To: paulmck@kernel.org, linux-toolchains@vger.kernel.org Cc: peterz@infradead.org, rostedt@goodmis.org, gregkh@linuxfoundation.org, keescook@chromium.org, torvalds@linux-foundation.org References: <9162660e-2d6b-47a3-bfa2-77bfc55c817b@paulmck-laptop> From: "H. Peter Anvin" In-Reply-To: <9162660e-2d6b-47a3-bfa2-77bfc55c817b@paulmck-laptop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/23/24 08:46, Paul E. McKenney wrote: > Hello! > > On the perhaps unlikely off-chance that any of this is of interest. > > Thanx, Paul On the contrary, I find it quite interesting. I have been in contact with both the C and C++ committee. > ------------------------------------------------------------------------ > > List of proposals with clickable links: > > https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log > > N3089 _Optional: a type qualifier to indicate pointer nullability > Proposes _Optional to tag pointer parameters such that > dereferencing the pointer without first checking for NULL gets > a compiler warning. > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3089.pdf > > N3190 Extensions to the preprocessor for C2Y > Proposes a number of macros, including things that return a > count of their arguments. > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3090.htm Some of these are *extremely* useful; in fact I believe I asked for some of these when I previously contacted one of the C committee members. One big motivator is making a size-safe printf(). That being said, they are missing some important bits, in particular #embed needs to be able to be expressed as _Embed() for the same reason that #pragma has _Pragma(); in fact #embed needs it even more, as if there is something you really want to macroize. #do and #foreach are mentioned but not defined. I'm wondering how useful these are if they can't be macroized themselves. At that point it might be better to have a proper macro function language. > N3194 Case range expressions > No fewer than 421 files in the Linux kernel use the "..." syntax, > as in "case 1 ... 3", but there are other syntaxes... So they > are proposing "::" instead. My guess is that "..." won't be > going away anytime soon. :: would be a disaster for C++ compatibility, and I'm feeling that C might end up needing to support C++ namespaces or some other mechanism like that. .. would be better if ... is unacceptable, or [foo,bar]. Inconsistent with range syntax for initializers if that is standard (I don't remember.) > N3195 Named loops > Placing a goto label before a loop allows a break/continue to > target that loop in case of nesting. ... which so many languages already support as an extension. > n3203 Strict order of expression evaluation > I do like it. The 1980s were over a long time ago. The question is: is this going to wreck havoc with performance. The C++ reference implies it won't, though. > N3199 Improved __attribute__((cleanup)) Through defer > N3198 Conditionally Supported Unwinding > The Linux kernel is starting to use __attribute__((cleanup)) > via guard(), with 40 files making use of this. It is not clear > to me whether or not either of these proposals would be useful > to the Linux kernel. > > N3201 Operator Overloading Without Name Mangling v2 > I have seen Linux-kernel interest in *function* overloading, but > not in operator overloading. Nevertheless... > > The trick here is to associate a given operator with a function, > so that the name-mangling becomes essentially a manual operation. It's kind of odd. It feels a bit like doing C++ backwards... Thanks for the heads-up. I think I'm going to reach out and chat with these folks. -hpa