Message-ID: <aXdiyLn3vxV2P807@devuan>
Date: Mon, 26 Jan 2026 13:49:16 +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 5/6] alx-0081r2 - array parameters of 0 elements

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

	Cc: Martin Uecker <uecker@...raz.at>
	Acked-by: Doug McIlroy
	Acked-by: Andrew Clayton <ac@...segv.uk>
	Cc: Alex Celeste <alexg.nvfp@...il.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>

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

Powered by blists - more mailing lists