New dialect flag: -farray-parameters-are-const

[alejandro-colomar]

This would change the dialect to make array parameters implicitly const.

The following code:

	int
	foo(int size, char buf[100], pid_t pid)
	{
		if (stprintf(buf, _Countof(buf), "/proc/%d/", pid) == -1)
			return -1;
		...
		return 0;
	}

would be equivalent to

	int
	foo(int size, char buf[const 100], pid_t pid)
	{
		if (stprintf(buf, _Countof(buf), "/proc/%d/", pid) == -1)
			return -1;
		...
		return 0;
	}

This would allow one to safely use _Countof() with array parameters, without the pointer being advanced accidentally, which would turn the size information outdated.

We can't make this the default behavior, as it would break existing code, but programmers might want to change the behavior in their own programs (I do). That would make it so that we don't need to write const in every array parameter to be able to use _Countof() on them. (I've written a proposal for extending _Countof() to work on array parameters, and a constraint would be that they need to be const-qualified.)

It is also morally appropriate, as these pointers represent arrays (even if they are not), so it wouldn't make sense to try to modify the address.

This closes part of the gap between array parameters and arrays.

See GCC proposal: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121271

See standard proposal (draft): https://www.alejandro-colomar.es/src/alx/alx/wg14/alx-0056.git/

Cc: @AaronBallman

Related: #150953

[alejandro-colomar]

Here's a copy of the standard proposal draft:

Name
	alx-0056r0 - implicitly const-qualified array parameters

Principles
	-  Uphold the character of the language.
	-  Keep the language small and simple.
	-  Avoid ambiguities.
	-  Do not leave features in an underdeveloped state.
	-  Avoid quiet changes.
	-  Enable secure programming.

Category
	Array parameters

Author
	Alejandro Colomar <alx@kernel.org>

History
	<https://www.alejandro-colomar.es/src/alx/alx/wg14/alx-0056.git/>

	r0 (2025-07-30):
	-  Initial draft.

See also
	<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121271>

Rationale
	Some programmers are confused by the fact that array parameters
	are really pointers, and not arrays.

	The differences are:

	-  Array parameters may be null.  (Unless [static] is used.)
	-  sizeof(), typeof(), and _Generic() treat them as pointers.
	-  The adjusted pointers can be modified by assignment.

	The first one is natural.  Many APIs need to be able to take
	an array of a null pointer, so that's okay.

	The second one, we can't change it lightly, as it would silently
	change the meaning of existing programs.

	The third one, we can change it.  That would make alx-0054
	--which proposes extending _Countof() to be usable with array
	parameters-- usable with existing array parameters, without
	having to clutter them all with 'const'.

	This is a breaking change, but not a silent one.  Compilers
	would start diagnosing modifications of the pointer value where
	it is modified.  This is something we anticipate in our charter:

		Avoid quiet changes

		Changes that alter the meaning of existing code cause
		problems.  Breaking changes that require diagnostic
		messages are easily detected.  Avoid silent changes that
		cause a working program to behave differently without
		requiring a diagnostic message.  [...]

	In reality, programmers that use array notation are expected to
	not change the pointer value, so this would be uncommon.

Recommended practice
	Compilers could add a flag -farray-parameters-are-const to
	enable this behavior in old dialects, and a flag
	-fno-array-parameters-are-const to revert to old behavior for
	compatibility.

Future directions
	A stronger change would be that sizeof(), typeof(), and
	_Generic() take it as if it were a real array.

	But that's a silent change, which needs to be more careful.
	I expect to add that as an extension in implementations as
	-farray-parameters-are-arrays, which I recommend implementations
	add already.  Once that is widespread, it could be reasonable to
	standardize on that.

Proposed wording
	Based on N3550.

    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.
	+within the [ and ] of the array type derivation,
	+and <b>const</b>,
	+which is always added implicitly.
	 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.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Alejandro Colomar (alejandro-colomar)

This would change the dialect to make array parameters implicitly const.

The following code:

	int
	foo(int size, char buf[100], pid_t pid)
	{
		if (stprintf(buf, _Countof(buf), "/proc/%d/", pid) == -1)
			return -1;
		...
		return 0;
	}

would be equivalent to

	int
	foo(int size, char buf[const 100], pid_t pid)
	{
		if (stprintf(buf, _Countof(buf), "/proc/%d/", pid) == -1)
			return -1;
		...
		return 0;
	}

This would allow one to safely use _Countof() with array parameters, without the pointer being advanced accidentally, which would turn the size information outdated.

We can't make this the default behavior, as it would break existing code, but programmers might want to change the behavior in their own programs (I do). That would make it so that we don't need to write const in every array parameter to be able to use _Countof() on them. (I've written a proposal for extending _Countof() to work on array parameters, and a constraint would be that they need to be const-qualified.)

It is also morally appropriate, as these pointers represent arrays (even if they are not), so it wouldn't make sense to try to modify the address.

This closes part of the gap between array parameters and arrays.

See GCC proposal: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121271>

See standard proposal (draft): <https://www.alejandro-colomar.es/src/alx/alx/wg14/alx-0056.git/>

Cc: @AaronBallman

Related: <#150953>

[llvmbot]

@llvm/issue-subscribers-c

Author: Alejandro Colomar (alejandro-colomar)

This would change the dialect to make array parameters implicitly const.

The following code:

	int
	foo(int size, char buf[100], pid_t pid)
	{
		if (stprintf(buf, _Countof(buf), "/proc/%d/", pid) == -1)
			return -1;
		...
		return 0;
	}

would be equivalent to

	int
	foo(int size, char buf[const 100], pid_t pid)
	{
		if (stprintf(buf, _Countof(buf), "/proc/%d/", pid) == -1)
			return -1;
		...
		return 0;
	}

This would allow one to safely use _Countof() with array parameters, without the pointer being advanced accidentally, which would turn the size information outdated.

We can't make this the default behavior, as it would break existing code, but programmers might want to change the behavior in their own programs (I do). That would make it so that we don't need to write const in every array parameter to be able to use _Countof() on them. (I've written a proposal for extending _Countof() to work on array parameters, and a constraint would be that they need to be const-qualified.)

It is also morally appropriate, as these pointers represent arrays (even if they are not), so it wouldn't make sense to try to modify the address.

This closes part of the gap between array parameters and arrays.

See GCC proposal: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121271>

See standard proposal (draft): <https://www.alejandro-colomar.es/src/alx/alx/wg14/alx-0056.git/>

Cc: @AaronBallman

Related: <#150953>

[frederick-vs-ja]

But as there's no mutable keyword in C, how can we opt-in the old behavior?

[alejandro-colomar]

With -fno-array-parameters-are-const, as usual. (These flags always come in pairs, right?)

[alejandro-colomar]

Or do you mean within the source code? If so, the answer is you can't.

Once you commit to this stricter dialect, by passing -farray-parameters-are-const, you must accept it, and create new pointer local variables if you want to assign them.

void
f(size_t n, int a[n])
{
    int *p = a;

    // You can freely change p, but not a.
}

This is closer to how real arrays behave.

[efriedma-quic]

See also #151240, which is about another difference between array parameters and actual arrays. (Specifically, the array bound doesn't actually specify the size of the array.)

[alejandro-colomar]

bdos() would in fact benefit from these changes to array parameters.

[frederick-vs-ja]

Or do you mean within the source code? If so, the answer is you can't.

Yeah. I meant in this way.

Given it's intended to disable restoring old behavior in source code, how about making the parameter behave like a "prvalue"/non-lvalue? I.e. given function parameter T a[N], a behaves as the result of lvalue conversion from the parameter in its scope, which disallows &a. Although we should furtherly determine what should happen when volatile is in [].