Hi all,

Am Montag, dem 15.12.2025 um 11:15 +0100 schrieb Alejandro Colomar:
> [CC += Martin]
> 
> Hi Paul,
> 

I assume we talk about function parameter declared as arrays, e.g.

void foo(int n, char buf[n]);

> > 
> > > > Also, how can one tell that GNU C supports this extension? Is there a 
> > > > sample
> > > > program illustrating the support?
> > > 
> > > Yup, here's one:
> > 
> > The examples you gave are only about what diagnostics GCC generates.
> 
> I don't know if GCC only uses [n] for diagnostics, or if it also does
> optimizations based on it.  Martin probably knows.

no, it is not used for optimization. It works similar to the access
attributes one could also use:

https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html

> 
> Also, I'm not sure GCC does anything different with [static n] than with
> [n], regarding optimizations (except for nonnull and n>0, of course).
> Martin probably also knows.

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


> 
> > Does
> > this mean the change you're proposing is a new constraint? That is, it'll be
> > a new part of the standard where the compiler is required to issue a
> > diagnostic, and where behavior is undefined if the constraint is violated?
> 
> Yes.
> 
> > 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). 

> 
> > And if I
> > understand things correctly, currently GCC issues some diagnostics not
> > required by C23 (which the standard of course allows; a compiler can issue
> > whatever diagnostics it likes),
> 
> Yes.
> 
> > but GCC goes ahead and generates code that
> > conforms to C23, that is, its optimizer doesn't take advantage of the new
> > constraint that I hypothesized above.
> 
> As I said above, I'm not sure.  However, I'd blidnly bet that whatever
> code GCC generates for [n], it also generates it for [static n].

GCC does not use [n] for optimization and uses [static n]
only for optimization by assuming the argument is not null.

> 
> > Am I on the right track here?
> > 
> > Part of the reason I'm asking, is I'm wondering if Gnulib should attempt to
> > package this sort of thing up. Our past experience in doing that (vla.h) was
> > a failure, and I'm reluctant to attempt anything unless I fully understand
> > the direction you're proposing.

A compiler conforming to ISO C23 will have support VLA syntax
in prototypes (real VLAs on the stack are still optional)

Martin



Reply via email to