From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 9CEE920A5F7 for ; Mon, 3 Feb 2025 16:06:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738598769; cv=none; b=qulTx9O4M4h2lodDTNBSOkQJnw4L4beWrdUKUueczSk6K2Tr+FhlcmF32Uv1uLkdE4Vo/VFjXKu0FHLVkq3NLHz47Jh8m+z0Qbbw6SZ3t0EYgLoriIK3/RfRwzdRBq8DXvpgKmwRjIILQqTW9gUQCCHO+8yNNOuNJXaOKUl5OTQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738598769; c=relaxed/simple; bh=16OsaxAzizFS4JPKhK54O58ifF8iCht/E74G61mPssc=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=WWlCLgKiMykgz9nctwx+JfWvzlfJWVwHOCfeZUGlAgAAADqCKyAyeuoqscSyuClmr/Dqr7Hh/pGtLsf5L+bRFMlDEsOf0/afA1bGhXCtz9ypN8WTwBgD7a+4EDRgq+2HAjKXMnDc7KbwIly/cjDq+nd6D8PRw2jqS7FbagpYkkk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Wc0FONQh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Wc0FONQh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1FA1BC4CED2 for ; Mon, 3 Feb 2025 16:06:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738598769; bh=16OsaxAzizFS4JPKhK54O58ifF8iCht/E74G61mPssc=; h=Date:From:To:Subject:Reply-To:From; b=Wc0FONQhQEADYoDAyASpbu4c/pu9s47mGBeJq3xCG2gaX37NP6jm8ha6oGFemSAoX vYcRcTtV5VpLbMHqrQtD9cfbdAxhJnmyq043txMyqvduWZbSoeK4VN+cFzzASwWU7i n+K8HCU3DxfakY5jwbn1CwIbu4N1m8XZq2DtWmnOoJCefx0Dz3z6AdBH5AREHFTAou maPgFo9to9M7rdpGabphN28RCWnrmD9uKt33jRxpZXgJT0pngGqplYvL7+cUvgBkg9 JFN1zdJxltj+waA7MO3lR4C7tCGEoOKeHILxFdv4x6iQxrhjPdLkC2IE272E//lMkn MGIFVhCInnlKg== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id B3191CE01D7; Mon, 3 Feb 2025 08:06:08 -0800 (PST) Date: Mon, 3 Feb 2025 08:06:08 -0800 From: "Paul E. McKenney" To: linux-toolchains@vger.kernel.org Subject: A few C++ proposals for the upcoming standards-committee meeting Message-ID: <07e2bfa1-e8d3-4de9-8dc1-54d675067908@paulmck-laptop> Reply-To: paulmck@kernel.org Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello! A few more proposals for the upcoming C++ Standards Committee meeting, which takes place next week. Thoughts? Thanx, Paul ------------------------------------------------------------------------ P2434R3 Nondeterministic pointer provenance https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2434r2.html This more clearly defines pointer lifetimes and provenance. It provides the underpinnings required to solve pointer lifetime-end zap for concurrent algorithms such as LIFO Push. Both P2414R5 and P3347R1 build on these underpinnings. P2414R5 Pointer lifetime-end zap proposed solutions https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2414r5.pdf Ergonomics building on top of P2434R3. This has been revised based on C++ mailing-list feedback: https://docs.google.com/document/d/19eXUzo_3-AgWGjIA1f0nlEXBqpCIp5dl1uMUN8QS6PI/edit?usp=sharing P3347R1 Invalid/Prospective Pointer Operations https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3347r1.pdf Proposes that non-comparison non-dereference operations on invalid pointers result in in-memory representations identical to those that would be obtained if those pointers were valid. P2843R1 Preprocessing is never undefined https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2843r1.pdf IFNDR = Ill Formed No Diagnostic Required. UB = Undefined Behavior This does not restrict the preprocessor, but instead moved from UB (which is only supposed to happen at runtime) to IFNDR, which is the compile-time counterpart to UB for compile-time issues. And the preprocessor runs entirely at compile-time, as recent Linux-kernel build-time issues have so amply demonstrated. P2883R1 `offsetof` Should Be A Keyword In C++26 https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2883r1.pdf Although offsetof is part of the C language, it can be a macro, which allows the Linux kernel to redefine it. And the Linux kernel does redefine it, for example, in v6.13: #undef offsetof #define offsetof(TYPE, MEMBER) __builtin_offsetof(TYPE, MEMBER) This paper proposed making offsetof a keyword. This is said to make for better interactions with C++ modules, which cannot export C++ preprocessor macros. I do not believe that the Linux community cares because the C preprocessor runs before keywords are identified. P3407R1 Make idiomatic usage of `offsetof` well-defined https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3407r1.html One of the issues called out in P2883R1 ("`offsetof` Should Be A Keyword In C++26') is that pointer arithmetic is UB in some cases. This could move the container_of() macro into the confines of the standard. P3125R3 constexpr pointer tagging https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3125r3.html This paper proposes standardizing tag bits in pointers. Various projects (including the Linux kernel) do this by going outside of the standard, which in theory should not be inconvenienced by a standard mechanism. But the devil is in the details... P3475R1 Defang and deprecate memory_order::consume https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3475r1.pdf This one is personally painful, but it is time... Blog post here: https://people.kernel.org/paulmck/the-immanent-deprecation-of-memory_order_consume P3501R0: The ad-dressing of cat https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3501r0.html This paper more clearly defines the relation between pointers, memory addresses, and the ordering of those memory addresses. However, the ordering of addreses of pointers to independent objects is still unspecified. P3566R0 You shall not pass `char*` - Safety concerns working with unbounded null-terminated strings https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3566r0.pdf This paper looks to deprecate char* from C++ in favor of std::string and std::string_view. Please note that this is for C++ rather than C. On the other hand, the Linux kernel has had the occasional issue with char* strings. P3568R0 break label; and continue label; https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3568r0.html Proposes allowing the "break" and "continue" statements to take labels, for example, to break out through multiple levels of "while" loops. A similar proposal was voted down in 2014, but the authors believe that it is time to try again. Their main justification is that "goto" may not appear in constant expressions, and they believe that compilers would be able to handle labeled "break" and "continue" statements.