Linux Hardening
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Martin Uecker <uecker@tugraz.at>,
	 Christopher Bazley <chris.bazley.wg14@gmail.com>,
	Alex Celeste <alexg.nvfp@gmail.com>,
	 Joseph Myers <josmyers@redhat.com>,
	Aaron Ballman <aaron@aaronballman.com>
Cc: Douglas McIlroy <douglas.mcilroy@dartmouth.edu>,
	 Bruno Haible <bruno@clisp.org>, Paul Eggert <eggert@cs.ucla.edu>,
	 Florian Weimer <fweimer@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>, Kees Cook <kees@kernel.org>,
	 Eric Biggers <ebiggers@kernel.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	 Daniel Thompson <danielt@kernel.org>,
	Daniel Lundin <daniel.lundin.mail@gmail.com>,
	 "Valentin V. Bartenev" <vbartenev@gmail.com>,
	Andrew Clayton <andrew@digital-domain.net>,
	 "Brian W. Kernighan" <bwk@cs.princeton.edu>,
	"G. Branden Robinson" <branden@debian.org>,
	 "Basil L. Contovounesios" <basil@contovou.net>,
	"Jason A. Donenfeld" <jason@zx2c4.com>,
	 Linus Torvalds <torvalds@linux-foundation.org>,
	onf <onf@disroot.org>, Rich Felker <dalias@libc.org>,
	 linux-hardening@vger.kernel.org,
	Alejandro Colomar <alx@kernel.org>
Subject: [RFC v3 4/6] alx-0079r2 - [static n] == non-null [n]
Date: Mon, 26 Jan 2026 13:49:02 +0100	[thread overview]
Message-ID: <aXdiutoeJyV2ZQh_@devuan> (raw)
In-Reply-To: <aXdhh1r7ePA5SrIE@devuan>

[-- 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 --]

  parent reply	other threads:[~2026-01-26 12:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <aXZM5O2mU2e3LJBJ@devuan>
2026-01-26 12:48 ` [RFC v3 0/6] Improve function parameters in ISO C2y Alejandro Colomar
2026-01-26 12:48   ` [RFC v3 1/6] alx-0077r3 - disallow function parameters of function type Alejandro Colomar
2026-01-26 12:48   ` [RFC v3 2/6] alx-0076r3 - incompatible array parameters Alejandro Colomar
2026-01-26 12:48   ` [RFC v3 3/6] alx-0078r2 - [static n] shouldn't access more than n elements Alejandro Colomar
2026-01-28  9:54     ` Daniel Thompson
2026-01-28 15:14       ` Alejandro Colomar
2026-01-26 12:49   ` Alejandro Colomar [this message]
2026-01-26 12:49   ` [RFC v3 5/6] alx-0081r2 - array parameters of 0 elements Alejandro Colomar
2026-01-28 10:14     ` Daniel Thompson
2026-01-28 15:21       ` Alejandro Colomar
2026-01-26 12:49   ` [RFC v3 6/6] alx-0080r1 - [static] without array length expression Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aXdiutoeJyV2ZQh_@devuan \
    --to=alx@kernel.org \
    --cc=aaron@aaronballman.com \
    --cc=alexg.nvfp@gmail.com \
    --cc=andrew@digital-domain.net \
    --cc=ardb@kernel.org \
    --cc=basil@contovou.net \
    --cc=branden@debian.org \
    --cc=bruno@clisp.org \
    --cc=bwk@cs.princeton.edu \
    --cc=chris.bazley.wg14@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dalias@libc.org \
    --cc=daniel.lundin.mail@gmail.com \
    --cc=danielt@kernel.org \
    --cc=douglas.mcilroy@dartmouth.edu \
    --cc=ebiggers@kernel.org \
    --cc=eggert@cs.ucla.edu \
    --cc=fweimer@redhat.com \
    --cc=jason@zx2c4.com \
    --cc=josmyers@redhat.com \
    --cc=kees@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=onf@disroot.org \
    --cc=torvalds@linux-foundation.org \
    --cc=uecker@tugraz.at \
    --cc=vbartenev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox