Re: A few proposals, this time from the C++ standards committee

["Paul E. McKenney" <paulmck@kernel.org>]

Hello!

And another set of potentially relevant papers, this time back to the C
standards committee.  I have commented on the ones that I expect would
be of interest, but please feel free to take a look at the others.

Thoughts?

							Thanx, Paul

------------------------------------------------------------------------

Full list:  https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3248.pdf
	The main purpose of the meeting is resolving formal issues,
	so this list is aspirational.

N3210 A String Type for C, Martin Uecker
	https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3210.pdf

	The proposed strings have explicit size of type size_t and a
	variable-length array of characters.  Maybe not of interest
	for the kernel, but of historical interest, given some of the
	late-1970s and early 1980s opposition to NUL-terminated strings.
	Of course, dedicating 64 bits to the string length would have
	been a no-go back then.  ;-)

N3211 Memory-Safety in C, Martin Uecker
	https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3211.pdf

	An interesting (and self-described) experiment to obtain
	compile-time checkable memory safety within the bounds and spirit
	of the C language.  There is a static mode that restricts the code
	to that which can be checked for memory safety at compile time,
	and a dynamic mode that includes run-time checks (and which is
	less restrictive.  The mode is selected with a pragma.

	There is not yet a prototype implementation, so early days.

N3212 Polymorphic Types, Martin Uecker
	https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3212.pdf

	Proposes function overloading.  This proposal avoids some
	typeof() issues by proposing a new _Typeof().  This proposal
	claims to permit changing a function to overloaded without
	changing the ABI for that function.

	If this works out, it might be used to replace some macros.
	The proposal calls out libffi as a target for this purpose.

	Also early days for this proposal.

N3214 Generic selection expression with a type operand, Aaron Ballman
	https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3214.pdf

	This proposes standardizing a Clang extension that extends
	the _Generic() keyword to take a type name as well as an
	assignment-expression.	This is a step towards allowing more
	natural generics in C.

	This appears to be a reasonably mature proposal, given the
	existing work in Clang.  The GCC folks might have opinions,
	of course.

N3223 The C Standard charter, Seacord et al.
	https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3223.pdf

	This document describes that the C standards committee is working
	towards and what they take into account in their work.

N3254 Accessing byte arrays, v4, Seacord et al.
	https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3254.pdf

	This document proposes standardizing GCC's approach for casting
	between structures and arrays of bytes, addresssing one annoying
	case of undefined behavior.  Atomics are an issue on deep embedded
	platforms, and one way forward is to make support for casting
	to and from atomics optional.

	This appears to be a reasonably mature proposal, given the
	existing work in GCC.  The Clang folks might have opinions,
	of course.

n3234 The semantics of the restrict qualifier, Jens Gustedt
	https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3234.htm

	This document attempts to formalize and rationalize the semantics
	of the C-language "restrict" keyword.  I have not yet read it
	carefully enough to have an informeed opinion on it, other than
	on the bravery of the author.  ;-)

	My perhaps overly cynical guess is that the Linux kernel will
	want to stick with its current command-line approach to this
	issue, but who knows?

n3243 A Memory model with Synchronization based type aliasing V1,
	Eskil Steenberg Hald
	https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3243.pdf

	This document's purpose is to allow the compiler more freedom
	to optimize in the face of pointer casts by introducing some
	additional undefined behavior.	It also introduces the notion
	of an aliasing barrier, which might well avoid much of the damage.
	In addition, the author does explicitly note the need to avoid
	breaking existing code, even if that code does have UB.  One
	surprising (to me) quote:

		"Our current thinking is that, perhaps the best way
		forward is to define an alternative memory model for C,
		based on these ideas, current implementations, existing
		code, and borrowing some from the Linux kernel memory
		model, and using external standards such as posix for
		concurrency."

	Perhaps it is time to refine the LKMM formalizations surrounding
	dependencies, especially given another surprising quote for an
	issue with the current C memory model: "Numerous issues with
	the concurrency model, like dependent reads."  The surprise is
	that the issue is stated to be with the language's concurrency
	model instead of with the dependencies themselves.

	This is early days for this proposal, and thus a good time to
	review and provide feedback.

N3244 Slay Some Earthly Demons I, Martin Uecker
	https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3244.pdf

	This proposal takes on a number of cases of undefined behavior,
	recommending compiler diagnostics in some cases and removing or
	weakening the undefinedness in others.