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

[Daniel Thompson <daniel@riscstar.com>]

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.