Hi Paul,

On Mon, Dec 15, 2025 at 08:47:36AM -0800, Paul Eggert wrote:
> On 2025-12-15 03:37, Martin Uecker wrote:
> > I assume we talk about function parameter declared as arrays, e.g.
> > 
> > void foo(int n, char buf[n]);
> 
> Yes.
> 
> 
> > For GCC, [static] is identical to using the nonnull attribute which
> > affects both optimization and warnings depending on compiler
> > flags.  I think clang behaves similar with respect to [static].
> 
> That's my impression as well: i.e., neither GCC nor clang fully optimize
> [static n] in the way that the designers of [static n] intended (i.e., that
> generated code can immediately dereference a[0] .. a[n-1]); they merely
> treat [static n] as a nonnull indication.

If you agree that neither GCC or Clang optimize [static n], and I
presume that no compilers in the world do that...

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.

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.

> > > > 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>

Attachment: signature.asc
Description: PGP signature

Reply via email to