Extend _Countof() to work with array parameters

[alejandro-colomar]

Hi!

Below is a draft of a proposal for the C Committee which is under discussion at the moment. I've also proposed this feature in GCC, where I'll implement it soon. This is the natural evolution of the _Countof operator.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121275

Cc: @AaronBallman

Have a lovely day!
Alex

---

Name
	alx-0054r3 - _Countof array parameters

Principles
	-  Uphold the character of the language.
	-  Keep the language small and simple.
	-  Avoid ambiguities.
	-  Pay attention to performance.
	-  Codify existing practice to address evident deficiencies.
	-  Do not leave features in an underdeveloped state.
	-  Avoid quiet changes.
	-  Enable secure programming.

	And from previous charters:

	C11:
	-  No invention, without exception.

	C23:
	-  APIs should be self-documenting when possible.

Category
	Do the Right Thing(tm).

Author
	Alejandro Colomar <alx@kernel.org>

	Cc: Martin Uecker <uecker@tugraz.at>
	Cc: Christopher Bazley <chris.bazley.wg14@gmail.com>
	Cc: Kees Cook <keescook@chromium.org>
	Cc: Linus Torvalds <torvalds@linuxfoundation.org>
	Cc: Aaron Ballman <aaron@aaronballman.com>

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

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

	r1 (2025-07-28):
	-  tfix.
	-  Require that the array parameter is const-qualified.
	-  Add 'Future directions'.
	-  Mention 'Avoid quiet changes'.

	r2 (2025-07-28):
	-  tfix.

	r3 ():
	-  Link to GCC proposal to extend _Countof.

See also
	-  GCC proposal to extend _Countof:
	   <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121275>

	-  GCC diagnostic proposal:
	   -Wsizeof-array
	   <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121270>

	-  GCC dialect flag proposal:
	   -fconst-array-parameters
	   <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121271>

	This proposal depends on:

	-  n2906 (2022-01-04; Uecker, "Consistency of Parameters Declared as Arrays (updates N2779)")
	   <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2906.pdf>

	This proposal would benefit from:

	-  n3433 (2025-01-25; Bazley, "Alternative syntax for forward declaration of parameters")
	   <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3433.pdf>

	This proposal conflicts with:

	-  n3656 (2025-07-27; Na, "Dependent attributes")
	   <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3656.pdf>

Rationale
	Historically, the C language had a way (the one and only way) to
	express that a parameter to a function is in reality an array.
	The ABI is that of a pointer, but usage is (almost) identical to
	an array (except for sizeof, and other operators that take into
	account the type of the operand)

		void foo(size_t n, int arr[n]);

	People have complained about them, mainly because they're
	dangerous.  People have tried to solve this with alternatives
	(fat pointers, std::array, std::vector, std::span, etc.) in C++.
	C has remained free of those things (for good) so far.  Now
	people try to add alternatives in C (n3656, Clang), disregarding
	all the principles mentioned above.

	A solution in C must integrate with the rest of the language,
	and that means using array syntax (as we've done forever in C),
	not changing the rules for parsing C code, not inventing
	completely new stuff at all.

	The solution has been there all the time; we only need to read
	all the information that is already present in most code: array
	parameter bounds.  Programmers are already conscious enough that
	they provide this information even if the compiler ignores it;
	it's good for their own readability (and some compilers already
	use it for diagnostics, including GCC).

	Now, we have _Countof().  This allows us to go farther than GCC.
	We can not only use that information for diagnostics, but we can
	use it for our actual code:

		void
		foo(size_t n, int a[const n])
		{
			for (size_t i = 0; i < _Countof(a); i++)
				a[i] = 0;
		}

	where _Countof(a) evaluates to 'n', the Right Thing.

	This would be directly usable in APIs where the size is visible
	before the array parameter, which is true in many internal APIs
	in projects.

	For the libc APIs, where this is not possible (due to the order
	of parameters), we'd need to standardize GCC's forward
	declaration of parameters, as proposed by n3433.

    const
	The array parameter must be const-qualified, to prevent it from
	being modified (advanced), which would turn the length
	information obsolete by the time _Countof() is used.

    Better than "dependent" attributes
	The approach with array notation and _Countof() not only enables
	some static analysis.  It allows writing better code.

	Let's say we want to call snprintf(3) safely.  I personally use
	the following wrappers (T for truncation):

		#define STPRINTF(s, fmt, ...)                         \
		(                                                     \
			stprintf(s, countof(s), fmt __VA_OPT__(,) __VA_ARGS__) \
		)


		[[gnu::format(printf, 3, 4)]]
		int
		stprintf(int size;
		    char s[restrict size], int size,
		    const char *restrict fmt, ...)
		{
			int      len;
			va_list  ap;

			va_start(ap, fmt);
			len = vstprintf(s, size, fmt, ap);
			va_end(ap);

			return len;
		}

		[[gnu::format(printf, 3, 0)]]
		int
		vstprintf(int size;
		    char s[restrict size], int size,
		    const char *restrict fmt, va_list ap)
		{
			int  len;

			len = vsnprintf(s, size, fmt, ap);
			if (len == -1)
				return -1;
			if (len >= size) {
				errno = E2BIG;
				return -1;
			}

			return len;
		}

	These allow one to call STPRINTF() on arrays like this:

		char  buf[PATH_MAX];

		if (STPRINTF(buf, "/proc/%d/", pid) == -1) {
			goto fail;

	Not needing to specify the array size at call site at all.
	By extending the _Countof operator to work on array parameters,
	we could do the same exact thing with them:

		int
		bar(int size, char buf[const 100], pid_t pid)
		{
			if (STPRINTF(buf, "/proc/%d/", pid) == -1) {
				return -1;

			...

			return 0;
		}

	This is only possible with _Countof(), and only possible with
	array notation.  _Countof() will never support pointers; that's
	a promise, by design.  Thus, this will not work with the
	attributes proposed in n3656.

    Arbitrarily complex prototypes
	This feature can be used for more complex functions, such as
	[v]seprintf(), proposed in alx-0049.

		[[gnu::format(printf, 3, 0)]]
		char *
		vseprintf(char *const restrict p, const char *restrict end;
		    char p[const restrict p ? end - p : 0],
		    const char end[restrict 0],
		    const char *restrict format, va_list ap)
		{
			int        len;
			ptrdiff_t  size;

			if (p == NULL)
				return NULL;

			len = vsnprintf(p, _Countof(p), fmt, ap);

			if (len == -1)
				return NULL;
			if (len >= _Countof(p)) {
				errno = E2BIG;
				return NULL;
			}

			return p + len;
		}

	Such a simple feature (4 lines added to the standard), provides
	very strong safety improvements to the C language, ruling out
	entire classes of bugs from the language; not only by enabling
	static analysis, but even better: by not being able to write
	them in the first place, with wrapper macros that call
	_Countof() as appropriate.

Prior art
	This reuses old C syntax with the meaning it always had, even if
	the standard ignores such syntax.

	And for the _Countof() extension, Martin and I are working on
	implementing this in GCC.

Future directions
    -Wsizeof-array
	We could make it a constraint violation to use sizeof(array).
	Now that we have _Countof(), it's safer to use it even for the
	size in bytes of an array, as

		_Countof(array) * sizeof(array[0])

	As it prevents accidentally using pointers.  And it would even
	work with array parameters, unlike sizeof().

	It's a breaking change, but it's not a silent one, so we're
	covered by 'Avoid quiet changes'.

    -fconst-array-parameters
	In the future, we could make all array parameters
	const-qualified.  I'd suggest compilers to add a flag that turns
	the dialect into that, which eventually turn into the default.

	This would also be a breaking change, but again we're covered by
	'Avoid quiet changes'.

    _Generic(), typeof()
	The combination of the two items above will make array
	parameters quite close to actual arrays.  Actually, almost
	indistinguishable, if not by _Generic() in combination with
	typeof().  We may want to tweak that too afterwards.  We'll see.

Proposed wording
	Based on N3550.

    6.5.4.5  The sizeof, _Countof, and alignof operators
	@@ Constraints, p1
	...
	 The _Countof operator shall only be applied to
	 an expression that has a complete array type,
	-or to the parenthesized name of such a type.
	+or to the parenthesized name of such a type,
	+or to a <b>const</b>-qualified array parameter of specified size.
	...

	@@ Semantics, p5
	 The _Countof operator yields
	 the number of elements of its operand.
	 The number of elements is determined from
	 the type of the operand.
	+If the operand is an array parameter,
	+the number of elements is determined from
	+the array type used in its declaration.
	 The result is an integer.
	 If the number of elements of the array type is variable,
	 the operand is evaluated;
	 otherwise,
	 the operand is not evaluated
	 and the expression is an integer constant expression.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Alejandro Colomar (alejandro-colomar)

Hi!

Below is a draft of a proposal for the C Committee which is under discussion at the moment. I've also proposed this feature in GCC, where I'll implement it soon. This is the natural evolution of the _Countof operator.

Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121275>

Cc: @AaronBallman

Have a lovely day!
Alex

---

Name
	alx-0054r3 - _Countof array parameters

Principles
	-  Uphold the character of the language.
	-  Keep the language small and simple.
	-  Avoid ambiguities.
	-  Pay attention to performance.
	-  Codify existing practice to address evident deficiencies.
	-  Do not leave features in an underdeveloped state.
	-  Avoid quiet changes.
	-  Enable secure programming.

	And from previous charters:

	C11:
	-  No invention, without exception.

	C23:
	-  APIs should be self-documenting when possible.

Category
	Do the Right Thing(tm).

Author
	Alejandro Colomar &lt;alx@<!-- -->kernel.org&gt;

	Cc: Martin Uecker &lt;uecker@<!-- -->tugraz.at&gt;
	Cc: Christopher Bazley &lt;chris.bazley.wg14@<!-- -->gmail.com&gt;
	Cc: Kees Cook &lt;keescook@<!-- -->chromium.org&gt;
	Cc: Linus Torvalds &lt;torvalds@<!-- -->linuxfoundation.org&gt;
	Cc: Aaron Ballman &lt;aaron@<!-- -->aaronballman.com&gt;

History
	&lt;https://www.alejandro-colomar.es/src/alx/alx/wg14/alx-0054.git/&gt;

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

	r1 (2025-07-28):
	-  tfix.
	-  Require that the array parameter is const-qualified.
	-  Add 'Future directions'.
	-  Mention 'Avoid quiet changes'.

	r2 (2025-07-28):
	-  tfix.

	r3 ():
	-  Link to GCC proposal to extend _Countof.

See also
	-  GCC proposal to extend _Countof:
	   &lt;https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121275&gt;

	-  GCC diagnostic proposal:
	   -Wsizeof-array
	   &lt;https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121270&gt;

	-  GCC dialect flag proposal:
	   -fconst-array-parameters
	   &lt;https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121271&gt;

	This proposal depends on:

	-  n2906 (2022-01-04; Uecker, "Consistency of Parameters Declared as Arrays (updates N2779)")
	   &lt;https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2906.pdf&gt;

	This proposal would benefit from:

	-  n3433 (2025-01-25; Bazley, "Alternative syntax for forward declaration of parameters")
	   &lt;https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3433.pdf&gt;

	This proposal conflicts with:

	-  n3656 (2025-07-27; Na, "Dependent attributes")
	   &lt;https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3656.pdf&gt;

Rationale
	Historically, the C language had a way (the one and only way) to
	express that a parameter to a function is in reality an array.
	The ABI is that of a pointer, but usage is (almost) identical to
	an array (except for sizeof, and other operators that take into
	account the type of the operand)

		void foo(size_t n, int arr[n]);

	People have complained about them, mainly because they're
	dangerous.  People have tried to solve this with alternatives
	(fat pointers, std::array, std::vector, std::span, etc.) in C++.
	C has remained free of those things (for good) so far.  Now
	people try to add alternatives in C (n3656, Clang), disregarding
	all the principles mentioned above.

	A solution in C must integrate with the rest of the language,
	and that means using array syntax (as we've done forever in C),
	not changing the rules for parsing C code, not inventing
	completely new stuff at all.

	The solution has been there all the time; we only need to read
	all the information that is already present in most code: array
	parameter bounds.  Programmers are already conscious enough that
	they provide this information even if the compiler ignores it;
	it's good for their own readability (and some compilers already
	use it for diagnostics, including GCC).

	Now, we have _Countof().  This allows us to go farther than GCC.
	We can not only use that information for diagnostics, but we can
	use it for our actual code:

		void
		foo(size_t n, int a[const n])
		{
			for (size_t i = 0; i &lt; _Countof(a); i++)
				a[i] = 0;
		}

	where _Countof(a) evaluates to 'n', the Right Thing.

	This would be directly usable in APIs where the size is visible
	before the array parameter, which is true in many internal APIs
	in projects.

	For the libc APIs, where this is not possible (due to the order
	of parameters), we'd need to standardize GCC's forward
	declaration of parameters, as proposed by n3433.

    const
	The array parameter must be const-qualified, to prevent it from
	being modified (advanced), which would turn the length
	information obsolete by the time _Countof() is used.

    Better than "dependent" attributes
	The approach with array notation and _Countof() not only enables
	some static analysis.  It allows writing better code.

	Let's say we want to call snprintf(3) safely.  I personally use
	the following wrappers (T for truncation):

		#define STPRINTF(s, fmt, ...)                         \
		(                                                     \
			stprintf(s, countof(s), fmt __VA_OPT__(,) __VA_ARGS__) \
		)


		[[gnu::format(printf, 3, 4)]]
		int
		stprintf(int size;
		    char s[restrict size], int size,
		    const char *restrict fmt, ...)
		{
			int      len;
			va_list  ap;

			va_start(ap, fmt);
			len = vstprintf(s, size, fmt, ap);
			va_end(ap);

			return len;
		}

		[[gnu::format(printf, 3, 0)]]
		int
		vstprintf(int size;
		    char s[restrict size], int size,
		    const char *restrict fmt, va_list ap)
		{
			int  len;

			len = vsnprintf(s, size, fmt, ap);
			if (len == -1)
				return -1;
			if (len &gt;= size) {
				errno = E2BIG;
				return -1;
			}

			return len;
		}

	These allow one to call STPRINTF() on arrays like this:

		char  buf[PATH_MAX];

		if (STPRINTF(buf, "/proc/%d/", pid) == -1) {
			goto fail;

	Not needing to specify the array size at call site at all.
	By extending the _Countof operator to work on array parameters,
	we could do the same exact thing with them:

		int
		bar(int size, char buf[const 100], pid_t pid)
		{
			if (STPRINTF(buf, "/proc/%d/", pid) == -1) {
				return -1;

			...

			return 0;
		}

	This is only possible with _Countof(), and only possible with
	array notation.  _Countof() will never support pointers; that's
	a promise, by design.  Thus, this will not work with the
	attributes proposed in n3656.

    Arbitrarily complex prototypes
	This feature can be used for more complex functions, such as
	[v]seprintf(), proposed in alx-0049.

		[[gnu::format(printf, 3, 0)]]
		char *
		vseprintf(char *const restrict p, const char *restrict end;
		    char p[const restrict p ? end - p : 0],
		    const char end[restrict 0],
		    const char *restrict format, va_list ap)
		{
			int        len;
			ptrdiff_t  size;

			if (p == NULL)
				return NULL;

			len = vsnprintf(p, _Countof(p), fmt, ap);

			if (len == -1)
				return NULL;
			if (len &gt;= _Countof(p)) {
				errno = E2BIG;
				return NULL;
			}

			return p + len;
		}

	Such a simple feature (4 lines added to the standard), provides
	very strong safety improvements to the C language, ruling out
	entire classes of bugs from the language; not only by enabling
	static analysis, but even better: by not being able to write
	them in the first place, with wrapper macros that call
	_Countof() as appropriate.

Prior art
	This reuses old C syntax with the meaning it always had, even if
	the standard ignores such syntax.

	And for the _Countof() extension, Martin and I are working on
	implementing this in GCC.

Future directions
    -Wsizeof-array
	We could make it a constraint violation to use sizeof(array).
	Now that we have _Countof(), it's safer to use it even for the
	size in bytes of an array, as

		_Countof(array) * sizeof(array[0])

	As it prevents accidentally using pointers.  And it would even
	work with array parameters, unlike sizeof().

	It's a breaking change, but it's not a silent one, so we're
	covered by 'Avoid quiet changes'.

    -fconst-array-parameters
	In the future, we could make all array parameters
	const-qualified.  I'd suggest compilers to add a flag that turns
	the dialect into that, which eventually turn into the default.

	This would also be a breaking change, but again we're covered by
	'Avoid quiet changes'.

    _Generic(), typeof()
	The combination of the two items above will make array
	parameters quite close to actual arrays.  Actually, almost
	indistinguishable, if not by _Generic() in combination with
	typeof().  We may want to tweak that too afterwards.  We'll see.

Proposed wording
	Based on N3550.

    6.5.4.5  The sizeof, _Countof, and alignof operators
	@@ Constraints, p1
	...
	 The _Countof operator shall only be applied to
	 an expression that has a complete array type,
	-or to the parenthesized name of such a type.
	+or to the parenthesized name of such a type,
	+or to a &lt;b&gt;const&lt;/b&gt;-qualified array parameter of specified size.
	...

	@@ Semantics, p5
	 The _Countof operator yields
	 the number of elements of its operand.
	 The number of elements is determined from
	 the type of the operand.
	+If the operand is an array parameter,
	+the number of elements is determined from
	+the array type used in its declaration.
	 The result is an integer.
	 If the number of elements of the array type is variable,
	 the operand is evaluated;
	 otherwise,
	 the operand is not evaluated
	 and the expression is an integer constant expression.

[llvmbot]

@llvm/issue-subscribers-c

Author: Alejandro Colomar (alejandro-colomar)

Hi!

Below is a draft of a proposal for the C Committee which is under discussion at the moment. I've also proposed this feature in GCC, where I'll implement it soon. This is the natural evolution of the _Countof operator.

Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121275>

Cc: @AaronBallman

Have a lovely day!
Alex

---

Name
	alx-0054r3 - _Countof array parameters

Principles
	-  Uphold the character of the language.
	-  Keep the language small and simple.
	-  Avoid ambiguities.
	-  Pay attention to performance.
	-  Codify existing practice to address evident deficiencies.
	-  Do not leave features in an underdeveloped state.
	-  Avoid quiet changes.
	-  Enable secure programming.

	And from previous charters:

	C11:
	-  No invention, without exception.

	C23:
	-  APIs should be self-documenting when possible.

Category
	Do the Right Thing(tm).

Author
	Alejandro Colomar &lt;alx@<!-- -->kernel.org&gt;

	Cc: Martin Uecker &lt;uecker@<!-- -->tugraz.at&gt;
	Cc: Christopher Bazley &lt;chris.bazley.wg14@<!-- -->gmail.com&gt;
	Cc: Kees Cook &lt;keescook@<!-- -->chromium.org&gt;
	Cc: Linus Torvalds &lt;torvalds@<!-- -->linuxfoundation.org&gt;
	Cc: Aaron Ballman &lt;aaron@<!-- -->aaronballman.com&gt;

History
	&lt;https://www.alejandro-colomar.es/src/alx/alx/wg14/alx-0054.git/&gt;

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

	r1 (2025-07-28):
	-  tfix.
	-  Require that the array parameter is const-qualified.
	-  Add 'Future directions'.
	-  Mention 'Avoid quiet changes'.

	r2 (2025-07-28):
	-  tfix.

	r3 ():
	-  Link to GCC proposal to extend _Countof.

See also
	-  GCC proposal to extend _Countof:
	   &lt;https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121275&gt;

	-  GCC diagnostic proposal:
	   -Wsizeof-array
	   &lt;https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121270&gt;

	-  GCC dialect flag proposal:
	   -fconst-array-parameters
	   &lt;https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121271&gt;

	This proposal depends on:

	-  n2906 (2022-01-04; Uecker, "Consistency of Parameters Declared as Arrays (updates N2779)")
	   &lt;https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2906.pdf&gt;

	This proposal would benefit from:

	-  n3433 (2025-01-25; Bazley, "Alternative syntax for forward declaration of parameters")
	   &lt;https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3433.pdf&gt;

	This proposal conflicts with:

	-  n3656 (2025-07-27; Na, "Dependent attributes")
	   &lt;https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3656.pdf&gt;

Rationale
	Historically, the C language had a way (the one and only way) to
	express that a parameter to a function is in reality an array.
	The ABI is that of a pointer, but usage is (almost) identical to
	an array (except for sizeof, and other operators that take into
	account the type of the operand)

		void foo(size_t n, int arr[n]);

	People have complained about them, mainly because they're
	dangerous.  People have tried to solve this with alternatives
	(fat pointers, std::array, std::vector, std::span, etc.) in C++.
	C has remained free of those things (for good) so far.  Now
	people try to add alternatives in C (n3656, Clang), disregarding
	all the principles mentioned above.

	A solution in C must integrate with the rest of the language,
	and that means using array syntax (as we've done forever in C),
	not changing the rules for parsing C code, not inventing
	completely new stuff at all.

	The solution has been there all the time; we only need to read
	all the information that is already present in most code: array
	parameter bounds.  Programmers are already conscious enough that
	they provide this information even if the compiler ignores it;
	it's good for their own readability (and some compilers already
	use it for diagnostics, including GCC).

	Now, we have _Countof().  This allows us to go farther than GCC.
	We can not only use that information for diagnostics, but we can
	use it for our actual code:

		void
		foo(size_t n, int a[const n])
		{
			for (size_t i = 0; i &lt; _Countof(a); i++)
				a[i] = 0;
		}

	where _Countof(a) evaluates to 'n', the Right Thing.

	This would be directly usable in APIs where the size is visible
	before the array parameter, which is true in many internal APIs
	in projects.

	For the libc APIs, where this is not possible (due to the order
	of parameters), we'd need to standardize GCC's forward
	declaration of parameters, as proposed by n3433.

    const
	The array parameter must be const-qualified, to prevent it from
	being modified (advanced), which would turn the length
	information obsolete by the time _Countof() is used.

    Better than "dependent" attributes
	The approach with array notation and _Countof() not only enables
	some static analysis.  It allows writing better code.

	Let's say we want to call snprintf(3) safely.  I personally use
	the following wrappers (T for truncation):

		#define STPRINTF(s, fmt, ...)                         \
		(                                                     \
			stprintf(s, countof(s), fmt __VA_OPT__(,) __VA_ARGS__) \
		)


		[[gnu::format(printf, 3, 4)]]
		int
		stprintf(int size;
		    char s[restrict size], int size,
		    const char *restrict fmt, ...)
		{
			int      len;
			va_list  ap;

			va_start(ap, fmt);
			len = vstprintf(s, size, fmt, ap);
			va_end(ap);

			return len;
		}

		[[gnu::format(printf, 3, 0)]]
		int
		vstprintf(int size;
		    char s[restrict size], int size,
		    const char *restrict fmt, va_list ap)
		{
			int  len;

			len = vsnprintf(s, size, fmt, ap);
			if (len == -1)
				return -1;
			if (len &gt;= size) {
				errno = E2BIG;
				return -1;
			}

			return len;
		}

	These allow one to call STPRINTF() on arrays like this:

		char  buf[PATH_MAX];

		if (STPRINTF(buf, "/proc/%d/", pid) == -1) {
			goto fail;

	Not needing to specify the array size at call site at all.
	By extending the _Countof operator to work on array parameters,
	we could do the same exact thing with them:

		int
		bar(int size, char buf[const 100], pid_t pid)
		{
			if (STPRINTF(buf, "/proc/%d/", pid) == -1) {
				return -1;

			...

			return 0;
		}

	This is only possible with _Countof(), and only possible with
	array notation.  _Countof() will never support pointers; that's
	a promise, by design.  Thus, this will not work with the
	attributes proposed in n3656.

    Arbitrarily complex prototypes
	This feature can be used for more complex functions, such as
	[v]seprintf(), proposed in alx-0049.

		[[gnu::format(printf, 3, 0)]]
		char *
		vseprintf(char *const restrict p, const char *restrict end;
		    char p[const restrict p ? end - p : 0],
		    const char end[restrict 0],
		    const char *restrict format, va_list ap)
		{
			int        len;
			ptrdiff_t  size;

			if (p == NULL)
				return NULL;

			len = vsnprintf(p, _Countof(p), fmt, ap);

			if (len == -1)
				return NULL;
			if (len &gt;= _Countof(p)) {
				errno = E2BIG;
				return NULL;
			}

			return p + len;
		}

	Such a simple feature (4 lines added to the standard), provides
	very strong safety improvements to the C language, ruling out
	entire classes of bugs from the language; not only by enabling
	static analysis, but even better: by not being able to write
	them in the first place, with wrapper macros that call
	_Countof() as appropriate.

Prior art
	This reuses old C syntax with the meaning it always had, even if
	the standard ignores such syntax.

	And for the _Countof() extension, Martin and I are working on
	implementing this in GCC.

Future directions
    -Wsizeof-array
	We could make it a constraint violation to use sizeof(array).
	Now that we have _Countof(), it's safer to use it even for the
	size in bytes of an array, as

		_Countof(array) * sizeof(array[0])

	As it prevents accidentally using pointers.  And it would even
	work with array parameters, unlike sizeof().

	It's a breaking change, but it's not a silent one, so we're
	covered by 'Avoid quiet changes'.

    -fconst-array-parameters
	In the future, we could make all array parameters
	const-qualified.  I'd suggest compilers to add a flag that turns
	the dialect into that, which eventually turn into the default.

	This would also be a breaking change, but again we're covered by
	'Avoid quiet changes'.

    _Generic(), typeof()
	The combination of the two items above will make array
	parameters quite close to actual arrays.  Actually, almost
	indistinguishable, if not by _Generic() in combination with
	typeof().  We may want to tweak that too afterwards.  We'll see.

Proposed wording
	Based on N3550.

    6.5.4.5  The sizeof, _Countof, and alignof operators
	@@ Constraints, p1
	...
	 The _Countof operator shall only be applied to
	 an expression that has a complete array type,
	-or to the parenthesized name of such a type.
	+or to the parenthesized name of such a type,
	+or to a &lt;b&gt;const&lt;/b&gt;-qualified array parameter of specified size.
	...

	@@ Semantics, p5
	 The _Countof operator yields
	 the number of elements of its operand.
	 The number of elements is determined from
	 the type of the operand.
	+If the operand is an array parameter,
	+the number of elements is determined from
	+the array type used in its declaration.
	 The result is an integer.
	 If the number of elements of the array type is variable,
	 the operand is evaluated;
	 otherwise,
	 the operand is not evaluated
	 and the expression is an integer constant expression.

[alejandro-colomar]

_Countof should return the declared number of elements in the array operand.

People may argue that the real array may be different. This is no different from the following code, already supported by _Countof (and actually, all operators):

#include <stdlib.h>

void foo(int n, int (*ap)[n]);

int
main(void)
{
	int (*ap)[42];

	ap = malloc(7 * sizeof(int));

	foo(_Countof(*ap), ap);
}

So, this is a matter of the type system in C being susceptible to the programmer lying, and not really an issue with _Countof or array parameters. _Countof should consistently return the declared number of elements, whether it is true or a lie.

[AaronBallman]

_Countof should return the declared number of elements in the array operand.

I think this introduces even more confusion in an area of the language that's already sufficiently baffling. It's not an array parameter, it's turned into a pointer for you despite using the array syntax. Unless that is resolved, this will continue to be a source of bugs. e.g.,

void func(int foo[const 12]) {
  sizeof(foo); // returns sizeof(int *)
  _Countof(foo); // returns 12
  typeof(foo) i = nullptr; // Was okay because it was int *i = nullptr, now it's an error because it's int i[const 12] = nullptr?
}

Or am I misunderstanding something?

[alejandro-colomar]

void func(int foo[const 12]) {
  sizeof(foo); // returns sizeof(int *)
  _Countof(foo); // returns 12
  typeof(foo) i = nullptr; // Was okay because it was int *i = nullptr, now it's an error because it's int i[const 12] = nullptr?
}

Or am I misunderstanding something?

For sizeof(foo), both GCC and Clang have a diagnostic that prevents bugs:

int func(int foo[const 12]);

int
func(int foo[const 12])
{
	return sizeof(foo);  // -Wsizeof-array-argument
}

alx@devuan:~/tmp$ clang -S sizeof.c 
sizeof.c:6:15: warning: sizeof on array function parameter will return size of 'int *const' instead of 'int[const 12]' [-Wsizeof-array-argument]
    6 |         return sizeof(foo);  // -Wsizeof-array-argument
      |                      ^
sizeof.c:4:10: note: declared here
    4 | func(int foo[const 12])
      |          ^
1 warning generated.

alx@devuan:~/tmp$ gcc -S sizeof.c 
sizeof.c: In function ‘func’:
sizeof.c:6:22: warning: ‘sizeof’ on array function parameter ‘foo’ will return size of ‘int * const’ [-Wsizeof-array-argument]
    6 |         return sizeof(foo);  // -Wsizeof-array-argument
      |                      ^
sizeof.c:4:10: note: declared here
    4 | func(int foo[const 12])
      |      ~~~~^~~~~~~~~~~~~

It's even enabled by default, so this is not an issue.

For typeof(), we're not changing that. The real type is still a pointer, for typeof(). The difference is that we're able to get the declared number of elements, regardless of it being a pointer.

[alejandro-colomar]

The thing is: never use sizeof() for arrays. Use _Countof(a) * sizeof(a[0]), for both arrays and array parameters. That's the safest thing.

See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121270

[alejandro-colomar]

So the idea is:

#define sizeof_array(a)  (_Countof(a) * sizeof((a)[0]))

void
func(int32_t foo[const 12])
{
  sizeof(foo);  // returns 8, but -Wsizeof-array-argument (default)
  _Countof(foo);  // returns 12
  sizeof_array(foo);  // returns 12 * 4
  typeof(foo) i = nullptr;  // Was okay and is okay.

  int32_t a[42];

  sizeof(a);  // returns 42 * 4, but -Wsizeof-array (proposed diagnostic, disabled by default)
  _Countof(a);  // returns 42
  sizeof_array(a);  // returns 42 * 4
  typeof(a) i = nullptr;  // Not okay.
}

[AaronBallman]

void func(int foo[const 12]) {
  sizeof(foo); // returns sizeof(int *)
  _Countof(foo); // returns 12
  typeof(foo) i = nullptr; // Was okay because it was int *i = nullptr, now it's an error because it's int i[const 12] = nullptr?
}

Or am I misunderstanding something?

For sizeof(foo), both GCC and Clang have a diagnostic that prevents bugs:

Assuming the user enables the diagnostic. This doesn't address the design concern that this makes the type even harder to reason about. It's a pointer as far as sizeof, typeof, and _Generic are concerned, it's an array as far as _Countof is concerned. I think this is trying to solve the problem from the wrong direction and I'm not yet convinced this is a good approach.