This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

This seems straightforward and avoids all the overloading you see.
Would
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.

Aldy


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]