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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXdiutoeJyV2ZQh_@devuan>
Date: Mon, 26 Jan 2026 13:49:02 +0100
From: Alejandro Colomar <alx@...nel.org>
To: Martin Uecker <uecker@...raz.at>, 
	Christopher Bazley <chris.bazley.wg14@...il.com>, Alex Celeste <alexg.nvfp@...il.com>, 
	Joseph Myers <josmyers@...hat.com>, Aaron Ballman <aaron@...onballman.com>
Cc: Douglas McIlroy <douglas.mcilroy@...tmouth.edu>, 
	Bruno Haible <bruno@...sp.org>, Paul Eggert <eggert@...ucla.edu>, 
	Florian Weimer <fweimer@...hat.com>, Jonathan Corbet <corbet@....net>, Kees Cook <kees@...nel.org>, 
	Eric Biggers <ebiggers@...nel.org>, Ard Biesheuvel <ardb@...nel.org>, 
	Daniel Thompson <danielt@...nel.org>, Daniel Lundin <daniel.lundin.mail@...il.com>, 
	"Valentin V. Bartenev" <vbartenev@...il.com>, Andrew Clayton <andrew@...ital-domain.net>, 
	"Brian W. Kernighan" <bwk@...princeton.edu>, "G. Branden Robinson" <branden@...ian.org>, 
	"Basil L. Contovounesios" <basil@...tovou.net>, "Jason A. Donenfeld" <jason@...c4.com>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, onf <onf@...root.org>, Rich Felker <dalias@...c.org>, 
	linux-hardening@...r.kernel.org, Alejandro Colomar <alx@...nel.org>
Subject: [RFC v3 4/6] alx-0079r2 - [static n] == non-null [n]

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@...nel.org>

	Cc: Martin Uecker <uecker@...raz.at>
	Acked-by: Doug McIlroy
	Acked-by: Andrew Clayton <ac@...segv.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@...uan:~/tmp$ cat ap.c 
		void f(int a[2]);
		int
		main(void)
		{
			int a[1];
			f(a);
		}
		alx@...uan:~/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>

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)