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