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
