A few C++ proposals for the upcoming standards-committee meeting

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.