RFC (C only): [[gnu::allow_vla]] attribute to suppress -Wvla on a single declaration

[David Brown]

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 <david.brown@hesbynett.no> 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 <fweimer@redhat.com> 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
>>>>
>>>
>>
>