This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]: New warning option -Walloca
> > > Dave> Well, there's a thought: maybe poison should behave like warnings (i.e.
> > > Dave> be suppressed for the most part) when it comes to system headers?
> >
> > This sounds like it would work too.
> >
>
> Manuel> But then you won't get any warning when you use alloca through
> Manuel> another function or through a macro redefinition. Is that what you
> Manuel> really want?
If we could poison alloca, and ignore alloca's in system headers (for
example, by making "poison alloca" a warning, and using
-Wno-system-headers), we would miss cases where alloca is used thru
another function or macro in system headers.
What we really want is better control over stack usage. Dynamic stack
allocations thru the use of alloca complicate this. So the above
approach of poisoning allocas (minus system headers), while it would
catch most of the occurences of allocas in user code, wouldn't catch
them all. Ensuring that an application doesn't do VLAs/allocas at all
would mean that we modify system headers/libararies thats do use
alloca (ex: fstream.tcc, ostream.tcc, etc) - which might not be very
feasible?
Another approach is to change the behavior of alloca if a flag like
-fstack-check is specified, i.e., instead of alloca simply modifying
the stack pointer without checking for stack overflow, we would add a
stack probe to detect stack overflow.
What does -fstack-check do in the presence of allocas currently?
cheers,
-raksit