This is the mail archive of the
mailing list for the GCC project.
Re: RFA: new pass to warn on questionable uses of alloca() and VLAs
On 07/11/2016 01:56 PM, Martin Sebor wrote:
On 07/11/2016 09:40 AM, Aldy Hernandez wrote:
On 07/11/2016 11:08 AM, Martin Sebor wrote:
Hey, I'm all for different options. It would definitely be easier for
me :). I wast trying really hard to use -Wvla= and keep the current
-Wvla meaning the same. Though I see your point about using -Wvla* but
using different variables for representing -Wvla and -Wvla=blah.
The easiest thing would be:
-Wvla: Current behavior (warn on everything).
-Wvla-larger-than=xxxx: Warn on unbounded VLA and bounded VLAs > xxxx.
-Walloca: Warn on every use of alloca (analogous to -Wvla).
-Walloca-larger-than=xxxx: Warn on unbounded alloca and bounded allocas
This seems straightforward and avoids all the overloading you see.
this be ok with everyone?
I like the consistency.
Given the common root with -Wlarger-than=N, what do envision the effect
of setting -Wlarger-than=N to be on the two new options?
FWIW, I tend to view -Wlarger-than= and certainly -Wframe-larger-than=
not warning on alloca larger than N as a defect. It could be fixed by
simply hooking -Walloca-larger-than= up to it.
I'm not touching any of these independent options. -Wvla-larger-than=
and -Walloca-larger-than= will be implemented independently of whatever
-Wlarger-than= and -Wframe-larger-than=. Any problems with these last
two options can be treated indpendently (PRs).
Strictly speaking there is no defect in -Wframe-larger-than= because
it's documented not to warn for alloca or VLAs. I asked because it
seems like an unnecessary (and IMO undesirable) limitation that could
be easily removed as part of this patch. Not removing it, OTOH, and
providing a separate solution, feels like highlighting the limitation.
With the new options, users interested in detecting all forms of
excessive stack allocation will be able to do so but not using
a single option. Instead, they will need to use all three.
I'll address this as a follow-up patch.