On Fri, 27 Feb 2026, 17:18 Yair Lenga, <[email protected]> wrote: > Hi, > > I'm not sure I agree with your statement that nobody liked this > proposal. I believe most of the feedback was positive on the > functionality - with many people suggesting short term alternatives on > how this can be (partially) solved with existing functionality (the > macro approach). I think most people recognized the limitation of the > macro approach. > > Some people suggested expanding the proposal (e.g., support C++, > generic functionality to modify diagnostic level (warning, error, > info, none) for any warning.in a statement/block/function scope). I > reviewed them and for practical reasons (significantly increased > effort, complexity, risk) - I'm sticking with the "narrow" scope. I > apologize if this was not clear from my summary. > > Specifically - the -Wvla-larger-than would fall into expanding the > scope to generalize the functionality. In projects i'm working with, >
The question was not about supporting that warning in your proposal, it was why you can't use that warning option instead of -Wvla. If you want use VLAs with bounded sizes, that's exactly what they option is for. Don't use -Wvla which warns about all VLAs, use the option that only warns about ones that are bigger than some limit that you specify. we use all the larger-than warnings - (as warnings) - as we always > want to be alerted when allocation crosses a certain boundary- so that > a small upgrade to #define that impact allocation will not go > unnoticed. > > Yair > > On Fri, Feb 27, 2026 at 9:33 AM Jonathan Wakely <[email protected]> > wrote: > > > > On Fri, 27 Feb 2026 at 14:01, Yair Lenga via Gcc <[email protected]> > wrote: > > > > > > Hello GCC maintainers, > > > > > > I recently proposed an attribute to suppress -Wvla on a single > declaration. > > > Thank you to everyone who provided feedback. I would like to summarize > the > > > discussion and outline the next step. > > > > > > Macro-based solutions > > > > > > Several replies noted that the problem can be addressed today with a > macro > > > wrapping diagnostic pragmas, for example: > > > > > > #define ALLOW_VLA(decl) > > > _Pragma("GCC diagnostic push") > > > _Pragma("GCC diagnostic ignored "-Wvla"") > > > decl > > > _Pragma("GCC diagnostic pop") > > > > > > This approach is workable and is used in some code bases (including > ours). > > > However it has practical drawbacks: > > > > > > diagnostics originating from the macro expansion are less clear, > > > > > > tools such as static analyzers and refactoring tools may not interpret > > > the construct well, > > > > > > portability requires conditional definitions per compiler, > > > > > > the annotation is not attached to the declaration in the AST. > > > > > > In contrast, existing attributes such as [[maybe_unused]] and > [[fallthrough]] > > > attach intent directly to the relevant construct and are consistently > visible > > > to both the compiler and external tooling. > > > > > > Generalized diagnostic-control attributes > > > > > > There was also a suggestion to generalize this into attributes > controlling > > > arbitrary diagnostics and/or larger scopes (blocks, functions), for > example: > > > > > > [[gnu::diagnostic_ignored("-Wvla")]] { ... } > > > > > > While this is an interesting direction, it substantially increases > scope > > > (design of attribute semantics, interaction with existing diagnostic > pragmas, > > > lifetime rules, etc.). > > > > > > The motivation of the current proposal is narrower: for VLA > specifically, > > > the goal is to mark intentional and reviewed use at the point of > declaration, > > > rather than to provide a general warning-suppression mechanism. > > > > > > Usefulness and expected adoption > > > > > > A concern was raised that this may serve only limited use cases. > > > > > > My expectation is that projects enabling -Wvla (often as part of > stricter > > > safety profiles) occasionally need small, bounded VLAs where heap > allocation > > > or fixed limits are impractical. Today these are either hidden behind > macros > > > or require local pragma ranges. An attribute provides a clearer and > more > > > auditable expression of intent. > > > > I don't think you've addressed the -Wvla-larger-than=N option in this > summary. > > > > > > > > Next step > > > > > > Based on the feedback, I plan to proceed with a minimal implementation > > > restricted to: > > > > > > attribute applicable to a single VLA declaration, > > > > > > effect equivalent to suppressing -Wvla for that declaration only, > > > > > > no change to pragma behavior or other diagnostics. > > > > > > I will send a patch to gcc-patches for review. > > > > > > If there are concerns with this narrowed scope or the proposed > direction, > > > please let me know. > > > > How is this a narrowed scope? Isn't it just your original proposal, > > which nobody liked? >
