Hi Martin, On Mon, Dec 15, 2025 at 09:51:50PM +0100, Martin Uecker wrote: > 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.
You could ask GCC to implement Clang's [[gnu::nonnull]] which goes
inside the parameter list. That would remove the error-prone concerns.
#define NONNULL [[gnu::nonnull]]
int foo(int n, NONNULL char buf[n]);
I'm pretty sure you wouldn't call that ugly or error-prone. It is also
C23 standard.
> 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++).
Hopefully not, because I pretend to remove [static n] from the standard.
Or are you intending to allow this?
int bar(struct s *static p);
Or are you suggesting to use array notation even for non-array pointers?
I'd prefer Clang's _Nullable keyword, if we're going to do that.
> > 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.
I awas assuming that you pass [[gnu::nonnull]] apart from using [n].
You don't get any benefit with [[gnu::nonnull]] [n] vs [static n].
>
> 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
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
