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

David Brown david.brown@hesbynett.no
Fri Feb 27 10:42:11 GMT 2026


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



More information about the Gcc mailing list