Yair,
Thank you for that explanation - I think it makes it clearer why you are
looking for this specific attribute. I fully appreciate your point
about expecting it to be easier to implement a limited attribute than a
general "ignore warning X" attribute (though I don't know the details of
the GCC implementation here - perhaps it /is/ easy to get the effect of
inject general warning _Pragmas into the code). And I also fully
understand that macros have their disadvantages, including how they
interact with errors.
I am much less in agreement with your thoughts on VLAs in general. This
is, of course, a matter of opinion and experience, and will vary for
different development teams and coding standards - I am only saying how
/I/ see things for my work, and not implying that anyone else should
necessarily follow the same thoughts.
I work on small embedded systems - if you think your stacks are
restricted in your multi-threaded work, you are still have many orders
of magnitude more stack space than in my branch. I don't make heavy use
of "real" VLAs, but when I do so, it is to reduce the stack usage and as
a safer (with the help of -Werror=vla-larger-than= ) and significantly
more efficient alternative to malloc() for temporary resources, without
the risks of heap fragmentation. VLAs are not higher risk than any
other kind of local array unless you are failing to ensure the size is
reasonable - and if you are in general not being responsible about size
checks, VLAs are not much higher risk than malloc's.
I wrote "real" VLAs above, because in C this is also a VLA :
const int n = 10 * 20;
int xs[n];
There is no difference in features, safety or run-time efficiency
compared to writing "int xs[10 * 20];", but there can be significant
improvements in code clarity, flexibility and maintainability. (In C++,
such an array is a normal C-style array, it is not a VLA.)
And if you want to mark your use of VLAs clearly in code, I would think
that using #pragma's or a loud MACRO are quite good ways to achieve that!
David
On 27/02/2026 14:33, Yair Lenga via Gcc wrote:
David,
Thank you for sharing your opinion and suggestion. I would agree that
adding a general property to change diagnostic level for a specific
scope (statement, block or function) will be a good general purpose
solution to the specific issue that I presented. Few reasons I'm
proposed a very focused solution for VLA
- VLA usage goes beyond a "warning" - there are good technical
arguments to suggest the VLA declaration should be visibly
distinguished from fixed-size array. Working in a team that maintain
big code base, there are certain constructs that we want to
"stand-out" when we view a piece of code.
- The second, and probably most relevant for me is implementation -
SCOPE . Designing a generic solution, and correct implementation
require much broader expertise that implementing a solution. This will
require agreement and time from multiple contributors - not to mention
the scope of testing and the potential risk. I think "good things come
in small packages" applies here.
- The third reason for VLA - it's about the value added. It's not a
niche, it a real issue for any large system, especially
multi-threaded, which always need to "budget" the usage of stacks.
Many GCC options are used by small number of "high-value" projects -
Linux Kernel is good example - and sometimes those practices become
the standard. The new C23 "official" attributes (maybe-unused, fall
through, reproducible, ...) have all started as compiler specific
extensions. Hopefully, VLA will join them, one they, ...
Regardless, If the GCC team/contributors (specifically, those who have
expertise in the GCC diagnostic sub-system/internal) will propose such
a project - I will vote 200% to go forward with it.
Just to clarify. My team ALREADY uses:
#define ALLOW_VLA(decl) _Pragma"(... push") ; _Pragma("... ignoed
vla") ; decl ; _Pragma("... pop") - it works but has many quirks. If
error messages from macros are confusing, some code scanners have
trouble parsing it (so the macro definition is conditional on gcc,
coverity, clang-tidy versions, ...). Lot of practical issue,
limitations. Does that job but leave "bad taste".
Yair
On Fri, Feb 27, 2026 at 5:42 AM David Brown <[email protected]> wrote:
Yair,
I am a gcc user, not a developer, so my opinions will be trumped by
those of the people actually doing the work.
As a user, one issue I see with GCC is the vast number of specialised
and badly or inconsistently named features - flags, attributes,
built_ins, etc. Most of these will be useful to some user (though some
are historic remainders, and some are primarily only useful internally
in GCC or for standard library implementations). But for any individual
user, there is a cost - it is more documentation to read, more time and
effort to find what you are looking for, more things for other
developers to understand when they first see them in code. And there is
a cost to developers - add a feature in now, and it must be maintained
ever after.
The reality is that if you add this attribute to GCC now, I am sure you
will use it in your code in the future - once it makes it through to a
release version of the compiler, and you have switched over to that
version. But will anyone else? How many developers do you think are
careful enough about detailed warning flags and reading the GCC manual
to know about -Wvla, feel they or their team are careless enough to use
VLAs accidentally, but know that they will have use of them occasionally
and know that -Wvla-larger-than would not be suitable? I would not
think many are in that position. And those that are, will usually be
happy with the warning push/pop idiom for code that is violating their
coding standard by using VLAs. If they need to do this often, they can
make a macro (using my or, better, Jonathan's syntax).
I agree that using an attribute is neater than pragma push/pop or a
macro. I agree that it is clearer in code. But I think it is an
extremely niche use-case, and I don't see it as a positive thing to add
more niche cases to the compiler and - more importantly for users - the
documentation.
This is why I suggested a general attribute for disabling warnings.
Then it would be adding one attribute for a wide range of uses. It is
one name to learn, and would cover most warnings - using the same name
as the warning flags (which GCC helpfully prints out when a warning is
triggered, so users don't even have to look that up).
It is also fairly easy to make a macro for disabling a specific warning
like -Wvla - but for a general DISABLE_WARNING macro, the quoting really
is tricky.
David
On 27/02/2026 01:23, Yair Lenga via Gcc wrote:
Florian,
Thanks for your suggestion. I'm already using macros, but that results
in code that does not look like "C" any more. New "C" developers that
are looking at hte code that uses DECLARE_VLA (or similar) macro -
have trouble understanding this new construct, how to use it,
limitations, etc (e.g., OK to use in `for (DECLARE_VLA(...) ; ; )`.
The attribute provide "in-langauge" support for the same functionality
in a way that is consistent with [[fallthru]], and similar.
Yair
On Thu, Feb 26, 2026 at 6:49 AM Florian Weimer <[email protected]> wrote:
* Yair Lenga via Gcc:
Hi Martin,
Yes - I believe something more "lightweight" than #pragma is needed.
What I've observed is that it's very "cumbersome", to write
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wvla"
double a[len] ;
#pragma GCC diagnostic push
Technically, can be "compacted" via #define - but then it's becoming
something that it's not "C" any more: e .g.
int foo(int how_many) {
DECLARE_VLA(ddd, double, how_many) ; // Compact but NOT C
int x = 5 ;
}
Could you achieve this effect if you used _Pragma? It can be part of
macros. The quoting is a bit tricky to get right, though. In your
case, that should be less of an issue because the pragma contents is not
dependent on macro arguments.
Thanks,
Florian
