On Tue, 20 Jan 2026, Alejandro Colomar wrote:
> +For a function declared as
> +
> +@smallexample
> +void f (int n, int a[n]);
> +@end smallexample
> +
> +A caller must provide a pointer to at least @code{n} elements,
> +and the function must not access more than @code{n} elements.
That's misleading. "must provide" suggests UB for violation, which is not
the case; this is just about warnings.
> +Type compatibility rules are also extended
> +to take this length into account.
That's also misleading, when it's about warnings rather than errors.
> +void j (int n, int a[n]);
> +void j (int n, int a[n + 1]);
Given that ISO C defines both of those to mean [*] as the array dimension,
this is also misleading (and suggests much trickier questions about what
happens with [(n)+(1)] or [1 + n] or [n - -1] or similar - which is why
it's hard to define any kind of constraints here).
*In the specific case of _Countof and parameter forward declarations*,
what needs to be defined is more constrained. In the case of function
prototype scope, it just needs to be clear whether _Countof gets a
constant length or a non-constant one that is treated as [*], and, in the
case of a constant length, which constant length if there's more than one
(and it would be possible to add a constraint when multiple constant
lengths are present for the same array parameter but disagree, since that
doesn't have the issues with comparisons that there are for non-constant
expressions). In the case of function definitions, if all the lengths get
evaluated on function entry, either you have UB for non-constant lengths
disagreeing or you avoid UB by defining exactly which of those lengths
applies at each point for the purposes of _Countof (given that those
lengths are of no significance except for _Countof).
--
Joseph S. Myers
[email protected]
