Re: A few proposals from the C standards committee

["H. Peter Anvin" <hpa@zytor.com>]

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