Am Montag, dem 15.12.2025 um 18:17 +0100 schrieb Alejandro Colomar:
> Hi Paul,
>
> On Mon, Dec 15, 2025 at 08:47:36AM -0800, Paul Eggert wrote:
>
> Then I don't see why gnulib would want to have this code:
>
> $ grepc -h -C1 VLA_ELEMS .
> #ifdef __STDC_NO_VLA__
> # define VLA_ELEMS(n)
> #else
> # define VLA_ELEMS(n) static n
> #endif
>
> Instead of just using
>
> #ifdef __STDC_NO_VLA__
> # define VLA_ELEMS(n)
> #else
> # define VLA_ELEMS(n) n
> #endif
>
> plus using __attribute__((__nonnull__())) appropriately.
The "just" goes into the wrong direction.
int foo(int n, char buf[static n]);
is nicer and simpler than
int foo(int n, char buf[n])
__attribute__((__nonnull__(2));
which is uglier, non-standard, and error prone as you
need to count the arguments.
Also the former is required to be supported by all ISO C23 standards,
so there at least some hope that one could drop the #ifdef at some
point in the future (but probably you still need one for C++).
>
> Every compiler that "supports" (i.e., ignores) [static n] will similarly
> support (i.e., ignore) [n]. You're not getting any benefit from typing
> that extra keyword.
You do: You get warnings when you pass a null pointer, you get sanitizer
checking when you pass a null pointer, you get a warning if you compare
this argument against null, and you get optimizations based on the fact
that it is not null.
Martin
>
> > > > > If so, this isn't an *extension* to C23/C17/etc.; it's a new
> > > > > *restriction*:
> > > > > some valid C23/C17/etc. programs will become invalid in C2y.
> > > >
> > > > Yes. Although, such programs are already nonsense, IMO.
> > > > People would do well revising that their uses of [n] are correct.
> > >
> > > Making something undefined is not a restriction, it
> > > simply means the program is not strictly conforming (almost no
> > > program is).
> >
> > OK, but that is a restriction from the point of view of portable code. Even
> > if GCC decided to not change its semantics other compilers could, and
> > there's a good chance they would eventually. And this would mean that
> > portable code, such as Gnulib, would need to be written to conform to this
> > new restriction.
>
> Yes, please make sure all of your code conforms to this tighter future
> specification. Anyway, GCC will be increasing diagnostics about it.
> And hopefully, we'll make it standard soon.
>
> > I don't think Gnulib would be affected by this new restriction, though.
> > Gnulib is portable all the way back to C99, and the a[n] style is nearly
> > useless in C99 so Gnulib hardly ever uses it and when it does it's as a
> > quasi-comment in code that already conforms to the new restriction.
>
>
> Have a lovely night!
> Alex
