On Wed, 21 Jan 2026, Alejandro Colomar wrote:
> Hi Joseph,
>
> On Wed, Jan 21, 2026 at 05:25:55PM +0000, Joseph Myers wrote:
> > > > > +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.
> > >
> > > I am indeed suggesting a constraint violation and subsequent UB if the
> > > diagnostic is ignored.
> >
> > We certainly shouldn't introduce UB for such code that is entirely valid
> > in ISO C.
>
> How about promoting it to a default error first? That would be
> a constraint violation. I'll also start writing a proposal for C2y.
Didn't Martin already have a proposal in that area (N2906, albeit not
dealing with VLAs; see my comments on it in [SC22WG14.21542], Thu, 3 Feb
2022 23:01:35 +0000)? Duplicative proposals rather than working together
on an improved and updated version aren't helpful.
> My bad. How about this:
>
> void k (int n, int (*p)[n]; int n, int (*p)[n+1]) {}
>
> Currently, we say that the types must match, which makes it UB. But if
> we change to using compatibility rules, that would still be UB because
> these are evaluated, so n3685::6.7.7.3p6 would apply.
That would indeed be UB based on compatibility. Whether such UB is needed
for an array parameter where the given length is only visible to _Countof
(if that _Countof feature is added) is less clear.
--
Joseph S. Myers
[email protected]
