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