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

[alejandro-colomar]

GCC ticket: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121331

Cc: @AaronBallman

This is a stronger version of -farray-parameters-are-const, proposed in
#151526.

It would make array parameters work as real arrays in every way: sizeof(), typeof(), _Generic(), ...

This would affect the function scope, but not it's callers.

Let's write some examples, to make it clear:

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

	char *a = malloc(100);
	f(100, a, 0);  // Ok; at call site pointers are valid.

	void
	g(int size, char buf[size], pid_t pid)
	{
		buf = NULL;  // error: assignment to expression with array type
	}

	void
	h(char *buf;
	  int size, char buf[size], pid_t pid);  // error: redeclaration with different type

	void
	i(char buf[];
	  int size, char buf[size], pid_t pid);  // okay

	void
	i(char buf[size];
	  int size, char buf[size], pid_t pid);  // okay

This is a breaking change, so it must be opt-in.

However, there shouldn't be much code that is relying on the old behavior, as most of it is already diagnosed by default.

---

With this flag enabled, the only difference with real arrays would be that these could be null. Other than that, they'd be real arrays.

(And also, of course, that one could use _Nullable within [], to mark the array as possibly null.)

[llvmbot]

@llvm/issue-subscribers-c

Author: Alejandro Colomar (alejandro-colomar)

GCC ticket: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121331>

Cc: @AaronBallman

This is a stronger version of -farray-parameters-are-const, proposed in
<#151526>.

It would make array parameters work as real arrays in every way: sizeof(), typeof(), _Generic(), ...

This would affect the function scope, but not it's callers.

Let's write some examples, to make it clear:

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

	char *a = malloc(100);
	f(100, a, 0);  // Ok; at call site pointers are valid.

	void
	g(int size, char buf[size], pid_t pid)
	{
		buf = NULL;  // error: assignment to expression with array type
	}

	void
	h(char *buf;
	  int size, char buf[size], pid_t pid);  // error: redeclaration with different type

	void
	i(char buf[];
	  int size, char buf[size], pid_t pid);  // okay

	void
	i(char buf[size];
	  int size, char buf[size], pid_t pid);  // okay

This is a breaking change, so it must be opt-in.

However, there shouldn't be much code that is relying on the old behavior, as most of it is already diagnosed by default.

---

With this flag enabled, the only difference with real arrays would be that these could be null. Other than that, they'd be real arrays.

(And also, of course, that one could use _Nullable within [], to mark the array as possibly null.)

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Alejandro Colomar (alejandro-colomar)

GCC ticket: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121331>

Cc: @AaronBallman

This is a stronger version of -farray-parameters-are-const, proposed in
<#151526>.

It would make array parameters work as real arrays in every way: sizeof(), typeof(), _Generic(), ...

This would affect the function scope, but not it's callers.

Let's write some examples, to make it clear:

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

	char *a = malloc(100);
	f(100, a, 0);  // Ok; at call site pointers are valid.

	void
	g(int size, char buf[size], pid_t pid)
	{
		buf = NULL;  // error: assignment to expression with array type
	}

	void
	h(char *buf;
	  int size, char buf[size], pid_t pid);  // error: redeclaration with different type

	void
	i(char buf[];
	  int size, char buf[size], pid_t pid);  // okay

	void
	i(char buf[size];
	  int size, char buf[size], pid_t pid);  // okay

This is a breaking change, so it must be opt-in.

However, there shouldn't be much code that is relying on the old behavior, as most of it is already diagnosed by default.

---

With this flag enabled, the only difference with real arrays would be that these could be null. Other than that, they'd be real arrays.

(And also, of course, that one could use _Nullable within [], to mark the array as possibly null.)

[frederick-vs-ja]

I guess this optional can also affect C++, although C++ doesn't have [static N] parameter, and such a parameter can only be of a constant-length array type. In C++, the parameter possibly acts as a light-weight span<T, N> (where N is not dynamic_extent).

[alejandro-colomar]

I guess this optional can also affect C++, although C++ doesn't have [static N] parameter, and such a parameter can only be of a constant-length array type. In C++, the parameter possibly acts as a light-weight span<T, N> (where N is not dynamic_extent).

Indeed, this is a C version of span, where the number of elements is whatever is within []. C++ could benefit from this lighter feature.