[RFC v3 0/6] Improve function parameters in ISO C2y

[RFC v3 0/6] Improve function parameters in ISO C2y

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

Hi!

I've written a set of drafts for proposals for ISO C2y.  Each of them is
minimal, and they all together vastly improve the specification of
function parameters (especially those declared with array type), with
the purpose of increasing the safety of the C language.

Please review these proposals, and comment any feedback (including any
other related proposals you'd suggest).  I'll try to incorporate
feedback before publishing these as N-documents (in a week or so).  Feel
free to publicly express approval with tags such as 'Acked-by:' or
'Reviewed-by:', which I'll incorporate in the proposals, which will
signal the committee that users are interested in the changes.

This 3rd revision is posted in the linux-hardening@ mailing list
(previous iterations were offlist).

I'll send the proposals as replies to this email, as if it were a usual
patch set.  List of draft proposals:

	[RFC v3 1/6] alx-0077r3 - disallow function parameters of function type
	[RFC v3 2/6] alx-0076r3 - incompatible array parameters
	[RFC v3 3/6] alx-0078r2 - [static n] shouldn't access more than n elements
	[RFC v3 4/6] alx-0079r2 - [static n] == non-null [n]
	[RFC v3 5/6] alx-0081r2 - array parameters of 0 elements
	[RFC v3 6/6] alx-0080r1 - [static] without array length expression


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[RFC v3 1/6] alx-0077r3 - disallow function parameters of function type

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 5442 bytes --]

Name
	alx-0077r3 - disallow function parameters of function type

Principles
	-  Uphold the character of the language.
	-  Avoid quiet changes.

	And from previous charters:

	C23:
	-  APIs should be self-documenting when possible.

Category
	Language; function parameters.

Authors
	Alejandro Colomar <alx@kernel.org>
	Alex Celeste <alexg.nvfp@gmail.com>

	Cc: Martin Uecker <uecker@tugraz.at>
	Acked-by: Bruno Haible <bruno@clisp.org>
	Acked-by: Doug McIlroy
	Acked-by: Andrew Clayton <ac@sigsegv.uk>

History
	<https://www.alejandro-colomar.es/src/alx/alx/std/wg14/alx-0077.git/>

	r0 (2026-01-24):
	-  Initial draft.

	r1 (2026-01-25):
	-  Re-title.

	r2 (2026-01-25):
	-  Acked-by Bruno.
	-  Add Comments section.

	r3 (2026-01-26):
	-  Acked-by.
	-  Tweak the constraint in p3 instead of adding a new one.
	-  Co-authored-by Alex Celeste.
	-  ffix
	-  Add Celeste's comment about the C89/C90 rationale and K&R.

Abstract
	A function parameter of function type is adjusted to a pointer:

		void f(void fp(void));

	is adjusted to

		void f(void (*fp)(void));

	This is unnecessary and confusing; let's disallow it.

Discussion
	I've never seen any code written declaring a function parameter
	of function type.  Unlike array parameters, this adjustment
	seems to be seldom used, if at all.

	We can turn this into a constraint violation, which will
	require that the few users of this quirk of C to tweak their
	declarations to declare a pointer type (which is what these
	parameters have always been).

	I've tried finding such uses with a search engine, but didn't
	find anything; it could be that there are no uses, or it could
	be that it's hard to write a regex that would find this.  FWIW,
	the standard has one example, just to document this weird
	allowance, and uses the usual pointer to function syntax
	elsewhere.

	Apart from resulting in more explicit code, this simplifies the
	wording, which would get more complex with other proposals that
	will modify compatibility rules regarding adjustment (it would
	require specifying some exceptions).

Comments
	On 2026-01-25T19:48:04+0100, Bruno Haible wrote:
	> I saw such a function parameter of function type once in 25 years of
	> C programming, and I found it confusing.
	>
	> This is an incompatible change to the language. But the impact on
	> existing code is so small that it's worth it.

	---

	On 2026-01-25T18:19:02-0500, Douglas McIlroy wrote:
	> All six proposals look eminently reasonable.  They simplify
	> the language and remove surprises.  I suspect these proposals
	> will invalidate very few existing programs.  In any event, the
	> required corrections will improve the legibility and
	> maintainability of such programs.
	>
	> Doug McIlroy

	---

	On 2026-01-26T02:27:02+0000, Alex Celeste wrote:
	> I was surprised not to find any comment in the C90 Rationale
	> about this.
	>
	> KnR1 says that 'since a reference to an array in any context
	> (in particular as an actual parameter) is taken to mean a
	> pointer to the first element of the array, declarations of
	> formal parameters declared ‘‘array of...’’ are adjusted to
	> read ‘‘pointer to ...’’.' There's no mention of functions in
	> this part, even though the KnR1 language does explicitly
	> describe using "bare" function identifiers to decay to
	> function pointers.
	>
	> This honestly feels like something that was added for
	> stylistic consistency.  Function pointers were already
	> well-developed before this became a language feature.
	> Combined with the fact that you _can't_ use a function type in
	> a definition of a thing with that type, and using it in an
	> external declaration creates something incompatible with an
	> object of function pointer type, and I think this was an
	> attempt at consistency that ended up creating an inconsistency
	> instead.
	> The [...] example does look unintentional to me for that
	> reason.

Proposed wording
	Based on N3685.

    6.7.7.4  Function declarators
	@@ Constraints, p3
	 After adjustment,
	 the parameters in a parameter type list
	 in a function declarator
	 that is part of a definition of that function
	-shall not have incomplete type.
	+shall have complete object type.

	@@ Semantics, p8
	-A declaration of a parameter
	-as "function returning type"
	-shall be adjusted
	-to "pointer to function returning type",
	-as in 6.3.3.1.

	@@ p15
	 In the determination
	 of type compatibility and of a composite type,
	 each parameter declared with
	-function or array type
	+array type
	 is taken as having the adjusted type
	 and each parameter declared with qualified type
	 is taken as having the unqualified version of its declared type.

    6.9.2  Function definitions
	@@ Semantics, p15
	 EXAMPLE 2 To pass one function to another, one can say
		int f(void);
		/* ... */
	-	g(f);
	+	g(f);  /* or g(&f); */
	 Then the definition of g can read
		void g(int (*funcp)(void))
		{
			/* ... */
			(*funcp)();  /* or funcp(); */
		}
	-or, equivalently,
	-	void g(int func(void))
	-	{
	-		/* ... */
	-		func();  /* or (*func)(); */
	-	}

	## I added 'g(&f)' for consistency with comments that show
	## alternate valid syntax; it seems an accidental omission that
	## could be fixed editorially.

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[RFC v3 2/6] alx-0076r3 - incompatible array parameters

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 7063 bytes --]

Name
	alx-0076r3 - incompatible array parameters

Principles
	-  Uphold the character of the language.
	-  Codify existing practice to address evident deficiencies.
	-  Avoid quiet changes.
	-  Enable secure programming.

	And from previous charters:

	C23:
	-  APIs should be self-documenting when possible.

Category
	Language; array parameters.

Authors
	Alejandro Colomar <alx@kernel.org>
	Martin Uecker <uecker@tugraz.at>

	Acked-by: Doug McIlroy
	Acked-by: Andrew Clayton <ac@sigsegv.uk>

History
	<https://www.alejandro-colomar.es/src/alx/alx/std/wg14/alx-0076.git/>

	r0 (2026-01-23):
	-  Initial draft.

	r1 (2026-01-24):
	-  Add a principle.
	-  Don't break parameters of function type (but see alx-0077).
	-  Document that this also applies to [static n].
	-  Remove superfluous line in diff.
	-  Clarify that the array type is incomplete.
	-  Add 'See also'.
	-  ffix

	r2 (2026-01-25):
	-  Take the two examples from N2906 (reordered).
	-  Add Martin as co-author.

	r3 (2026-01-26):
	-  Acked-by.
	-  tfix

Abstract
	The following two function prototypes violate a constraint:

		void f(int (*p)[2]);
		void f(int (*p)[2+1]);

	The following two function prototypes should be unacceptable,
	for consistency:

		void g(int a[2]);
		void g(int a[2+1]);

Discussion
	The prototypes above are obviously wrong.  If a program is
	compiled containing the above prototypes for g(), the programmer
	is clearly very confused, and there are high chances that the
	program will eventually overflow a buffer.

	Currently, a program containing

		void g(int a[2]);
		void g(int a[2+1]);

	is a valid program, because the array parameters are adjusted to
	pointers before checking for type compatibility.

	The standard (n3685) says in 6.7.7.4p3:

		Two function types are compatible
		if and only if all of the following hold:
			--  They specify compatible return types.
			--  The parameter type lists
			    agree in the number of parameters
			    and in whether the function is variadic or not.
			--  The corresponding parameters have compatible types.
		In the determination
		of type compatibility
		and of a composite type,
		each parameter declared with function or array type
		is taken as having
		the adjusted type
		and each parameter declared with qualified type
		is taken as having
		the unqualified version of its declared type.

	We could easily tweak that paragraph to say that the
	compatibility is tested before adjustment.  That would need a
	teak to make pointers compatible with arrays, though.  It would
	also need a tweak so that in function calls we still use the
	adjusted type.

    [static n]
	This change also makes the following be not compatible:

		void h(int a[static 2]);
		void h(int a[static 2+1]);

	This is intentional.  A future proposal will propose that
	a function declared with a parameter [static n] is not allowed
	to access more than n elements (and the current proposal already
	kind-of implies this).  Another future proposal will make
	[static n] and [n] equivalent, except for nullability of the
	pointer.

Prior art
	Both GCC and Clang already diagnose such code:

		alx@devuan:~/tmp$ cat ap.c 
		void g(int a[2]);
		void g(int a[2+1]);
		alx@devuan:~/tmp$ gcc -Wall -S ap.c 
		ap.c:2:12: warning: argument 1 of type ‘int[3]’ with mismatched bound [-Warray-parameter=]
		    2 | void g(int a[2+1]);
		      |        ~~~~^~~~~~
		ap.c:1:12: note: previously declared as ‘int[2]’
		    1 | void g(int a[2]);
		      |        ~~~~^~~~
		alx@devuan:~/tmp$ clang -Weverything -S ap.c 
		ap.c:2:12: warning: argument 'a' of type 'int[3]' with
		      mismatched bound [-Warray-parameter]
		    2 | void g(int a[2+1]);
		      |            ^
		ap.c:1:12: note: previously declared as 'int[2]' here
		    1 | void g(int a[2]);
		      |            ^
		1 warning generated.

See also
	N2906 (Uecker; "Consistency of Parameters Declared as Arrays (updates N2779)")
	That proposal is superseded by this one, which achieves the same
	goal with significantly less complexity.

	alx-0077r0 - function parameters of function type
	<https://www.alejandro-colomar.es/src/alx/alx/std/wg14/alx-0077.git/>

Comments
	On 2026-01-25T18:19:02-0500, Douglas McIlroy wrote:
	> All six proposals look eminently reasonable.  They simplify
	> the language and remove surprises.  I suspect these proposals
	> will invalidate very few existing programs.  In any event, the
	> required corrections will improve the legibility and
	> maintainability of such programs.
	>
	> Doug McIlroy

	---

	On 2026-01-26T02:01:16+0000, Alex Celeste wrote:
	> Like Martin - these all seem eminently reasonable to me.

Proposed wording
	Based on N3685.

    6.5.3.3  Function calls
	@@ Constraints, p2
	 The number of arguments
	 shall agree with
	 the number of parameters.
	 Each argument shall have a type such that
	 its value may be assigned to
	 an object with
	 the unqualified version of the type of
	-its corresponding parameter.
	+its corresponding adjusted parameter.

    6.7.7.4  Function declarators
	@@ Semantics, p15
	 Two function types are compatible
	 if and only if all of the following hold:
		--  They specify compatible return types.
		--  The parameter type lists
		    agree in the number of parameters
		    and in whether the function is variadic or not.
		--  The corresponding parameters have compatible types.
	 In the determination
	 of type compatibility
	 and of a composite type,
	-each parameter declared with function or array type
	+each parameter declared with array type
	 is taken as having
	-the adjusted type
	+the non-adjusted type,
	+each parameter declared with function type    ## \
	+is taken as having                            ## -} See below.
	+the adjusted type,                            ## /
	+each parameter declared with "pointer to object <i>type</i>"
	+is taken as having incomplete "array of <i>type</i>"
	+(the opposite of adjustment),
	 and each parameter declared with qualified type
	 is taken as having
	 the unqualified version of its declared type.

	## The three lines about function type are to not change
	## anything regarding function types in this proposal, as this
	## proposal intends to be mostly uncontroversial.  However, it
	## is cruft that shouldn't be there.  There's another proposal
	## for removing that: alx-0077.  If that other proposal is
	## accepted before this one (or at the same time), remove these
	## three lines here.

	@@ p21+1
	+EXAMPLE 6
	+The following are all compatible function prototype declarators:
	+	void g(int x[const 5]);
	+	void g(int x[5]);          // composite type
	+	void g(int *restrict x);
	+	void g(int x[*]);
	+	void g(int x[]);

	@@ p21+2
	+EXAMPLE 7
	+The following function prototype declarators
	+are not compatible:
	+	void g(int x[5]);
	+	void g(int x[3]);

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[RFC v3 3/6] alx-0078r2 - [static n] shouldn't access more than n elements

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3974 bytes --]

Name
	alx-0078r2 - [static n] shouldn't access more than n elements

Principles
	-  Uphold the character of the language.
	-  Codify existing practice to address evident deficiencies.
	-  Enable secure programming.

	And from previous charters:

	C23:
	-  APIs should be self-documenting when possible.

Category
	Language; array parameters.

Authors
	Alejandro Colomar <alx@kernel.org>
	Martin Uecker <uecker@tugraz.at>

	Acked-by: Doug McIlroy
	Acked-by: Andrew Clayton <ac@sigsegv.uk>

History
	<https://www.alejandro-colomar.es/src/alx/alx/std/wg14/alx-0078.git/>

	r0 (2026-01-25):
	-  Initial draft.

	r1 (2026-01-25):
	-  wfix.
	-  Co-authored by Martin.

	r2 (2026-01-26):
	-  Acked-by.
	-  tfix

Abstract
	The following function prototype requires an input with at least
	2 elements:

		void f(int a[static 2]);

	It should not use more than 2 elements, as those are not
	guaranteed to be available.  That is, the following function
	definition should be unacceptable:

		void f(int a[static 2])
		{
			a[7] = 0;
		}

Discussion
	It is a de-facto standard that functions declaring a [static n]
	parameter require at least n elements, and don't access more
	than n elements.  Most programmers that don't know the fine
	letter of the standard would assume that.  This has its roots in
	the older syntax, [n], which is not acknowledged by the
	standard, but has been historically used to document this as
	part of the API.

	Without this, [static n] is only useful for optimizations, but
	not for writing safe code, as the specification of [static n]
	doesn't provide the compiler with enough information to know
	whether array bounds will be violated.  This makes it a terrible
	UB foot-gun.

	Let's change the specification to make it safe.

Prior art
	GCC acknowledges this common understanding, and diagnoses such
	code:

		alx@devuan:~/tmp$ cat ap.c 
		void g(int a[static 3]);
		void f(int a[static 2])
		{
			g(a);
		}
		alx@devuan:~/tmp$ gcc -S ap.c 
		ap.c: In function ‘f’:
		ap.c:4:9: warning: ‘g’ accessing 12 bytes in a region of size 8 [-Wstringop-overflow=]
		    4 |         g(a);
		      |         ^~~~
		ap.c:4:9: note: referencing argument 1 of type ‘int[3]’
		ap.c:1:6: note: in a call to function ‘g’
		    1 | void g(int a[static 3]);
		      |      ^

Future directions
	[n] should have the same properties regarding array bounds,
	thereby acknowledging the common understanding of what [n]
	means.  This will be addressed by a future proposal.

Comments
	On 2026-01-25T18:19:02-0500, Douglas McIlroy wrote:
	> All six proposals look eminently reasonable.  They simplify
	> the language and remove surprises.  I suspect these proposals
	> will invalidate very few existing programs.  In any event, the
	> required corrections will improve the legibility and
	> maintainability of such programs.
	>
	> Doug McIlroy

	---

	On 2026-01-26T02:01:16+0000, Alex Celeste wrote:
	> Like Martin - these all seem eminently reasonable to me.

Proposed wording
	Based on N3685.

    6.7.7.4  Function declarators
	@@ Semantics, p7
	 A declaration of a parameter as "array of type"
	 shall be adjusted to "qualified pointer to type",
	 where the type qualifiers (if any)
	 are those specified
	 within the [ and ]
	 of the array type derivation.
	 If the keyword static also appears
	 within the [ and ]
	 of the array type derivation,
	 then for each call to the function,
	 the value of the corresponding actual argument
	 shall provide access to
	 the first element of an array
	 with at least as many elements
	-as specified by the size expression.
	+as specified by the array length expression,
	+and the function definition
	+shall not access an element
	+beyond the specified number of elements.

	## Editorially replace s/size/array length/ while at this.

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC v3 3/6] alx-0078r2 - [static n] shouldn't access more than n elements

[Daniel Thompson]

On Mon, Jan 26, 2026 at 01:48:49PM +0100, Alejandro Colomar wrote:
> Name
> 	alx-0078r2 - [static n] shouldn't access more than n elements
>
> Principles
> 	-  Uphold the character of the language.
> 	-  Codify existing practice to address evident deficiencies.
> 	-  Enable secure programming.
>
> 	And from previous charters:
>
> 	C23:
> 	-  APIs should be self-documenting when possible.
>
> Category
> 	Language; array parameters.
>
> Authors
> 	Alejandro Colomar <alx@kernel.org>
> 	Martin Uecker <uecker@tugraz.at>
>
> 	Acked-by: Doug McIlroy
> 	Acked-by: Andrew Clayton <ac@sigsegv.uk>
>
> History
> 	<https://www.alejandro-colomar.es/src/alx/alx/std/wg14/alx-0078.git/>
>
> 	r0 (2026-01-25):
> 	-  Initial draft.
>
> 	r1 (2026-01-25):
> 	-  wfix.
> 	-  Co-authored by Martin.
>
> 	r2 (2026-01-26):
> 	-  Acked-by.
> 	-  tfix
>
> Abstract
> 	The following function prototype requires an input with at least
> 	2 elements:
>
> 		void f(int a[static 2]);
>
> 	It should not use more than 2 elements, as those are not
> 	guaranteed to be available.  That is, the following function
> 	definition should be unacceptable:
>
> 		void f(int a[static 2])
> 		{
> 			a[7] = 0;
> 		}
>
> Discussion
> 	It is a de-facto standard that functions declaring a [static n]
> 	parameter require at least n elements, and don't access more
> 	than n elements.  Most programmers that don't know the fine
> 	letter of the standard would assume that.  This has its roots in
> 	the older syntax, [n], which is not acknowledged by the
> 	standard, but has been historically used to document this as
> 	part of the API.
>
> 	Without this, [static n] is only useful for optimizations, but
> 	not for writing safe code, as the specification of [static n]
> 	doesn't provide the compiler with enough information to know
> 	whether array bounds will be violated.  This makes it a terrible
> 	UB foot-gun.
>
> 	Let's change the specification to make it safe.

I don't see how the proposed wording change makes C safer, see below.


>     <snip>
>     6.7.7.4  Function declarators
> 	@@ Semantics, p7
> 	 A declaration of a parameter as "array of type"
> 	 shall be adjusted to "qualified pointer to type",
> 	 where the type qualifiers (if any)
> 	 are those specified
> 	 within the [ and ]
> 	 of the array type derivation.
> 	 If the keyword static also appears
> 	 within the [ and ]
> 	 of the array type derivation,
> 	 then for each call to the function,
> 	 the value of the corresponding actual argument
> 	 shall provide access to
> 	 the first element of an array
> 	 with at least as many elements
> 	-as specified by the size expression.
> 	+as specified by the array length expression,
> 	+and the function definition
> 	+shall not access an element
> 	+beyond the specified number of elements.

By limiting what the function definition may do, we are reducing the set
of valid programs. Won't that *increase* the level of undefined
behaviour in the language?

That will allow compilers to perform more aggressive local optimizations
(which is probably good) but I don't see how it will make things safer.
To make things safe would mean compilers changing their diagnostics, and
the prior art suggests compilers already warn on this.


Daniel.

Re: [RFC v3 3/6] alx-0078r2 - [static n] shouldn't access more than n elements

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 4999 bytes --]

Hi Daniel,

On 2026-01-28T09:54:37+0000, Daniel Thompson wrote:
> On Mon, Jan 26, 2026 at 01:48:49PM +0100, Alejandro Colomar wrote:
> > Name
> > 	alx-0078r2 - [static n] shouldn't access more than n elements
> >

[...]
> > Abstract
> > 	The following function prototype requires an input with at least
> > 	2 elements:
> >
> > 		void f(int a[static 2]);
> >
> > 	It should not use more than 2 elements, as those are not
> > 	guaranteed to be available.  That is, the following function
> > 	definition should be unacceptable:
> >
> > 		void f(int a[static 2])
> > 		{
> > 			a[7] = 0;
> > 		}
> >
> > Discussion
> > 	It is a de-facto standard that functions declaring a [static n]
> > 	parameter require at least n elements, and don't access more
> > 	than n elements.  Most programmers that don't know the fine
> > 	letter of the standard would assume that.  This has its roots in
> > 	the older syntax, [n], which is not acknowledged by the
> > 	standard, but has been historically used to document this as
> > 	part of the API.
> >
> > 	Without this, [static n] is only useful for optimizations, but
> > 	not for writing safe code, as the specification of [static n]
> > 	doesn't provide the compiler with enough information to know
> > 	whether array bounds will be violated.  This makes it a terrible
> > 	UB foot-gun.
> >
> > 	Let's change the specification to make it safe.
> 
> I don't see how the proposed wording change makes C safer, see below.
> 
> 
> >     <snip>
> >     6.7.7.4  Function declarators
> > 	@@ Semantics, p7
> > 	 A declaration of a parameter as "array of type"
> > 	 shall be adjusted to "qualified pointer to type",
> > 	 where the type qualifiers (if any)
> > 	 are those specified
> > 	 within the [ and ]
> > 	 of the array type derivation.
> > 	 If the keyword static also appears
> > 	 within the [ and ]
> > 	 of the array type derivation,
> > 	 then for each call to the function,
> > 	 the value of the corresponding actual argument
> > 	 shall provide access to
> > 	 the first element of an array
> > 	 with at least as many elements
> > 	-as specified by the size expression.
> > 	+as specified by the array length expression,
> > 	+and the function definition
> > 	+shall not access an element
> > 	+beyond the specified number of elements.
> 
> By limiting what the function definition may do, we are reducing the set
> of valid programs. Won't that *increase* the level of undefined
> behaviour in the language?

Yes, this proposal increases --at least theoretically-- the amount of
undefined in the language.  See below for why I say "theoretically".

> That will allow compilers to perform more aggressive local optimizations
> (which is probably good) but I don't see how it will make things safer.

Yes, that's true.  On the other hand, nobody is forcing compilers to
abuse UB to perform aggresive optimizations.  They may choose to refrain
from certain optimizations, and instead use the information exclusively
for diagnostics.

> To make things safe would mean compilers changing their diagnostics, and
> the prior art suggests compilers already warn on this.

GCC has partial support for this, precisely because it ignores the
specification of the standard, and de-facto considers this to be the
meaning of [static n] (and also of [n], FWIW).  GCC support for this is
incomplete at the moment, though.  But in the long term, yes, GCC
intends to diagnose like this.

On the other hand, Clang implements this per the C standard, which makes
it a quite bad implementation regarding array bounds.

	alx@devuan:~/tmp$ cat ap.c 
	void f(int a[static 2]);
	void f(int a[static 2])
	{
		a[1] = 0;
		a[2] = 0;  // UB
		a[3] = 0;  // UB
	}
	alx@devuan:~/tmp$ gcc -S ap.c -Wall -Wextra
	alx@devuan:~/tmp$ clang -S ap.c -Weverything
	ap.c:4:2: warning: unsafe buffer access [-Wunsafe-buffer-usage]
	    4 |         a[1] = 0;
	      |         ^
	ap.c:5:2: warning: unsafe buffer access [-Wunsafe-buffer-usage]
	    5 |         a[2] = 0;  // UB
	      |         ^
	ap.c:6:2: warning: unsafe buffer access [-Wunsafe-buffer-usage]
	    6 |         a[3] = 0;  // UB
	      |         ^
	3 warnings generated.

-Wunsafe-buffer-access is just noise.  Nothing is diagnosing the case
shown in the abstract.

The case shown in the 'Prior art' section is only diagnosed by GCC.

So, this proposal would force Clang to diagnose what GCC already
diagnoses.

About why this increase in UB is only theoretical: programs violating
this *already* have UB (with 99.99% certainty).  The UB is just not
visible to the compiler, but the program is already overflowing buffers
most likely.  By making that UB visible to the compiler, we increase the
chances that it will be diagnosed.  So, I'd say I'm not adding UB, but
rather moving it around to show up earlier.


Have a lovely day!
Alex

> Daniel.

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[RFC v3 4/6] alx-0079r2 - [static n] == non-null [n]

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3689 bytes --]

Name
	alx-0079r2 - [static n] == non-null [n]

Principles
	-  Uphold the character of the language.
	-  Codify existing practice to address evident deficiencies.
	-  Enable secure programming.

	And from previous charters:

	C23:
	-  APIs should be self-documenting when possible.

Category
	Language; array parameters.

Author
	Alejandro Colomar <alx@kernel.org>

	Cc: Martin Uecker <uecker@tugraz.at>
	Acked-by: Doug McIlroy
	Acked-by: Andrew Clayton <ac@sigsegv.uk>

History
	<https://www.alejandro-colomar.es/src/alx/alx/std/wg14/alx-0079.git/>

	r0 (2026-01-25):
	-  Initial draft.

	r1 (2026-01-25):
	-  wfix

	r2 (2026-01-26):
	-  Acked-by.

Abstract
	Everyone who has ever written [2] in an array parameter meant
	what a 10-year-old kid would guess.  Let's acknowledge it.

		void f(int a[2]);

Discussion
	It is a de-facto standard that functions declaring a [n]
	parameter require at least n elements (or NULL), and don't
	access more than n elements.  It is well known that this is not
	required by the standard, but that should be irrelevant.  The
	standard didn't acknowledge it for fear of breaking existing
	code, but

	1)  There should be absolutely no real code that would break by
	    such a change.

	2)  If any code wouldn't comply with this specification, it is
	    deeply broken, and is most likely already overflowing
	    buffers.

	Let's do the Right Thing(tm).

Prior art
	GCC acknowledges this common understanding, and diagnoses such
	code:

		alx@devuan:~/tmp$ cat ap.c 
		void f(int a[2]);
		int
		main(void)
		{
			int a[1];
			f(a);
		}
		alx@devuan:~/tmp$ gcc -S ap.c
		ap.c: In function ‘main’:
		ap.c:6:9: warning: ‘f’ accessing 8 bytes in a region of size 4 [-Wstringop-overflow=]
		    6 |         f(a);
		      |         ^~~~
		ap.c:6:9: note: referencing argument 1 of type ‘int[2]’
		ap.c:1:6: note: in a call to function ‘f’
		    1 | void f(int a[2]);
		      |      ^

See also
	<https://www.alejandro-colomar.es/src/alx/alx/std/wg14/alx-0078.git/>
	alx-0078 ("[static n] shouldn't access more than n elements")
	That proposal also changes this paragraph, but in a compatible
	way.

Comments
	On 2026-01-25T18:19:02-0500, Douglas McIlroy wrote:
	> All six proposals look eminently reasonable.  They simplify
	> the language and remove surprises.  I suspect these proposals
	> will invalidate very few existing programs.  In any event, the
	> required corrections will improve the legibility and
	> maintainability of such programs.
	>
	> Doug McIlroy

	---

	On 2026-01-26T02:01:16+0000, Alex Celeste wrote:
	> Like Martin - these all seem eminently reasonable to me.

Proposed wording
	Based on N3685.

    6.7.7.4  Function declarators
	@@ Semantics, p7
	 A declaration of a parameter as "array of type"
	 shall be adjusted to "qualified pointer to type",
	 where the type qualifiers (if any)
	 are those specified
	 within the [ and ]
	 of the array type derivation.
	-If the keyword static also appears
	-within the [ and ]
	-of the array type derivation,
	+If the length of such an array is specified,
	 then for each call to the function,
	+if
	 the value of the corresponding actual argument
	+is not a null pointer,
	+it
	 shall provide access to
	 the first element of an array
	 with at least as many elements
	 as specified by the size expression.
	+If the keyword static also appears
	+within the [ and ]
	+of the array type derivation,
	+then for each call to the function,
	+the corresponding actual argument
	+shall not be a null pointer.

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[RFC v3 5/6] alx-0081r2 - array parameters of 0 elements

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 4411 bytes --]

Name
	alx-0081r2 - array parameters of 0 elements

Principles
	-  Uphold the character of the language
	-  Codify existing practice to address evident deficiencies
	-  Enable secure programming

	And from previous charters:

	C23:
	-  APIs should be self-documenting when possible.

Category
	Language; array parameters.

Author
	Alejandro Colomar <alx@kernel.org>

	Cc: Martin Uecker <uecker@tugraz.at>
	Acked-by: Doug McIlroy
	Acked-by: Andrew Clayton <ac@sigsegv.uk>
	Cc: Alex Celeste <alexg.nvfp@gmail.com>

History
	<https://www.alejandro-colomar.es/src/alx/alx/std/wg14/alx-0081.git/>

	r0 (2026-01-25):
	-  Initial draft.

	r1 (2026-01-25):
	-  Array length expressions shall be nonnegative.

	r2 (2026-01-26):
	-  Acked-by.
	-  Remove 'See also'.

Abstract
	Function parameters that have zero elements are common and safe.
	Let's acknowledge this, and allow array syntax for them.

Discussion
	The following code is valid:

		static inline wchar_t
		my_wmemset(size_t n, wchar_t *wcs, wchar_t wc)
		{
			return wmemset(wcs, wc, n);
		}

		wchar_t  a[42];

		my_wmemset(0, a + 42, L'x');

	It would be natural to be able to declare my_wmemset() as

		wchar_t my_wmemset(size_t n, wchar_t wcs[static n], wchar_t);

	However, that would result in UB for the call above, as the
	number of elements isn't allowed to be zero.  That restriction
	is superfluous, and harmful; let's remove it.

Future directions
	I'd like to allow any arrays of zero elements, but that needs
	to be more careful than for array parameters.  A future proposal
	will address that.

Comments
	On 2026-01-25T18:19:02-0500, Douglas McIlroy wrote:
	> All six proposals look eminently reasonable.  They simplify
	> the language and remove surprises.  I suspect these proposals
	> will invalidate very few existing programs.  In any event, the
	> required corrections will improve the legibility and
	> maintainability of such programs.
	>
	> Doug McIlroy

	---

	On 2026-01-26T02:01:16+0000, Alex Celeste wrote:
	> Like Martin - these all seem eminently reasonable to me.

Proposed wording
	Based on N3685.

    6.7.7.3  Array declarators
	@@ Constraints, p1
	 In addition to optional type qualifiers and the keyword static,
	 the [ and ] can delimit an expression or *.
	 If they delimit an expression,
	 called the array length expression,
	 the expression shall have an integer type.
	 If the expression is a constant expression,
	-it shall have a value greater than zero.
	+it shall have a nonnegative value.
	+An array length expression
	+that is a constant expression with value zero
	+shall appear only in
	+a declaration of a function parameter with an array type,
	+and then only in the outermost array type derivation.
	 The element type shall not be an incomplete or function type.
	 The optional type qualifiers and the keyword static
	 shall appear only in
	 a declaration of a function parameter with an array type,
	 and then only in the outermost array type derivation.

	@@ Semantics, p5
	 If the array length expression
	 is not an integer constant expression:
	 if it occurs in a declaration
	 at function prototype scope
	 or in a type name of a generic association (as described above),
	 it is treated as if it were replaced by *;
	 otherwise,
	 each time it is evaluated,
	-it shall have a value greater than zero.
	+it shall have a value greater than zero,
	+unless in the outermost array type derivation
	+of a function parameter with an array type,
	+in which case it shall have a nonnegative value.
	 The size of each instance of a variable length array type
	 does not change during its lifetime.
	 Where an array length expression
	 is part of the operand of the typeof or sizeof operators
	 and changing the value of the array length expression
	 would not affect the result of the operator,
	 it is unspecified
	 whether or not the array length expression is evaluated.
	 Where an array length expression is part of
	 the operand with a _Countof operator
	 and changing the value of the array length expression
	 would not affect the result of the operator,
	 the array length expression is not evaluated.
	 Where an array length expression is part of
	 the operand of an alignof operator,
	 that expression is not evaluated.

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC v3 5/6] alx-0081r2 - array parameters of 0 elements

[Daniel Thompson]

On Mon, Jan 26, 2026 at 01:49:16PM +0100, Alejandro Colomar wrote:
> Proposed wording
> 	Based on N3685.
>
>     6.7.7.3  Array declarators
> 	@@ Constraints, p1
> 	 In addition to optional type qualifiers and the keyword static,
> 	 the [ and ] can delimit an expression or *.
> 	 If they delimit an expression,
> 	 called the array length expression,
> 	 the expression shall have an integer type.
> 	 If the expression is a constant expression,
> 	-it shall have a value greater than zero.
> 	+it shall have a nonnegative value.
> 	+An array length expression
> 	+that is a constant expression with value zero
> 	+shall appear only in
> 	+a declaration of a function parameter with an array type,
> 	+and then only in the outermost array type derivation.

This change did not have any motivating example within the discussion.
Providing a motivational example showing why it is useful to allow array
parameters whose constant length is zero would be good.


Daniel.

Re: [RFC v3 5/6] alx-0081r2 - array parameters of 0 elements

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

Hi Daniel,

On 2026-01-28T10:14:23+0000, Daniel Thompson wrote:
> On Mon, Jan 26, 2026 at 01:49:16PM +0100, Alejandro Colomar wrote:
> > Proposed wording
> > 	Based on N3685.
> >
> >     6.7.7.3  Array declarators
> > 	@@ Constraints, p1
> > 	 In addition to optional type qualifiers and the keyword static,
> > 	 the [ and ] can delimit an expression or *.
> > 	 If they delimit an expression,
> > 	 called the array length expression,
> > 	 the expression shall have an integer type.
> > 	 If the expression is a constant expression,
> > 	-it shall have a value greater than zero.
> > 	+it shall have a nonnegative value.
> > 	+An array length expression
> > 	+that is a constant expression with value zero
> > 	+shall appear only in
> > 	+a declaration of a function parameter with an array type,
> > 	+and then only in the outermost array type derivation.
> 
> This change did not have any motivating example within the discussion.
> Providing a motivational example showing why it is useful to allow array
> parameters whose constant length is zero would be good.

Makes sense; I'll add that.

Here's a function that I use in shadow-utils:

	char *
	stpecpy(char dst[], const char end[];
	    char dst[dst?end-dst:0], const char end[0], const char *restrict src)
	{
		ssize_t  dlen;

		if (dst == NULL)
			return NULL;

		dlen = strtcpy(dst, src, end - dst);
		if (dlen == -1)
			return NULL;

		return dst + dlen;
	}

It's essentially the same as Plan9's strecpy(2), except that Plan9's
API has an important bug.

Here's a GCC bug that shows such a use case:
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036>


Have a lovely day!
Alex

> Daniel.

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[RFC v3 6/6] alx-0080r1 - [static] without array length expression

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2580 bytes --]

Name
	alx-0080r1 - [static] without array length expression

Principles
	-  Keep the language small and simple

Category
	Language; array parameters.

Author
	Alejandro Colomar <alx@kernel.org>

	Cc: Martin Uecker <uecker@tugraz.at>
	Acked-by: Doug McIlroy
	Acked-by: Andrew Clayton <ac@sigsegv.uk>

History
	<https://www.alejandro-colomar.es/src/alx/alx/std/wg14/alx-0080.git/>

	r0 (2026-01-25):
	-  Initial draft.

	r1 (2026-01-26):
	-  Acked-by.
	-  tfix

Abstract
	'static' in [static n] means that the argument shall be
	non-null.  That is entirely independent of the length of the
	array parameter, so it doesn't make sense requiring the length
	to be specified.  Lift that restriction.

Discussion
	While the standard, for a long time, claimed that 'static' in
	[static n] was about the length of the array, it is well known
	that this is only true in paper.  In practice, programmers use
	[n] with that meaning.

	'static' in [static n] has a different meaning (see also
	alx-0079): it says that the argument shall be non-null.

See also
	<https://www.alejandro-colomar.es/src/alx/alx/std/wg14/alx-0079.git/>
	alx-0079 ("[static n] == non-null [n]")
	alx-0079 should be applied before alx-0080.  Otherwise, the
	semantics would be undefined.

Comments
	On 2026-01-25T18:19:02-0500, Douglas McIlroy wrote:
	> All six proposals look eminently reasonable.  They simplify
	> the language and remove surprises.  I suspect these proposals
	> will invalidate very few existing programs.  In any event, the
	> required corrections will improve the legibility and
	> maintainability of such programs.
	>
	> Doug McIlroy

	---

	On 2026-01-26T02:01:16+0000, Alex Celeste wrote:
	> Like Martin - these all seem eminently reasonable to me.

Proposed wording
	Based on N3685.

    6.7.7.1  Declarators :: General
	@@ Syntax, p1
	+array-qualifier-list:
	+	<b>static</b>(opt) type-qualifier-list
	+	type-qualifier-list <b>static</b>
	+
	+array-length-declarator:
	+	assignment-expression
	+	<b>*</b>
	+
	 array-declarator:
	-	direct-declarator <b>[</b> type-qualifier-list(opt) assignment-expression(opt) <b>]</b>
	-	direct-declarator <b>[ static</b> type-qualifier-list(opt) assignment-expression <b>]</b>
	-	direct-declarator <b>[</b> type-qualifier-list <b>static</b> assignment-expression <b>]</b>
	-	direct-declarator <b>[</b> type-qualifier-list(opt) <b>* ]</b>
	+	direct-declarator <b>[</b> array-qualifier-list(opt) array-length-declarator(opt) <b>]</b>

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]