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.
> > In the case of pointers to arrays:
> >
> > void k (int n, int (*p)[n]);
> > void k (int n, int (*p)[n + 1]);
> >
> > The relevant text is n3685::6.7.7.3p6:
>
> That's not relevant, since both of those declarations mean
>
> void k (int n, int (*p)[*]);
>
> and the array length expressions are never evaluated.
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.
Cheers,
Alex
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
