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 <[email protected]>
Cc: Martin Uecker <[email protected]>
Acked-by: Doug McIlroy
Acked-by: Andrew Clayton <[email protected]>
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>
signature.asc
Description: PGP signature
