Re: [PATCH]: New warning option -Walloca

["Seongbae Park (박성배, 朴成培)" <spark at google dot com>]

On 8/31/07, Kaveh R. GHAZI <ghazi@caip.rutgers.edu> wrote:
> On Fri, 31 Aug 2007, [EUC-KR] Seongbae Park (¹Ú¼º¹è, ÚÓà÷ÛÆ) wrote:
>
> > On 8/31/07, Kaveh R. GHAZI <ghazi@caip.rutgers.edu> wrote:
> > > On Fri, 31 Aug 2007, Raksit Ashok wrote:
> > >
> > > > > > > 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.
> > >
> > > A simpler approach would be to define alloca to something else *after* you
> > > include system headers.  E.g.:
> > >
> > > #define alloca dont_use_alloca
> > >
> > > Then any time someone uses alloca they get spanked by the compiler and/or
> > > linker.  This is stronger than poisoning because it affects the alloca
> > > calls that appear through macro expansions.  You can do this in a common
> > > header included across the whole project.  Each approach (poison vs macro)
> > > has its uses.
> >
> > This would work if your codebase has a common header
> > that every file (both the source and the header files) includes
> > before including anything else.
> > But most large projects (e.g. gcc) don't have such one,
> > or it's very difficult to ensure such a guarantee.
> > Seongbae
>
> I don't know about other projects, but GCC which you reference has had a
> common header (system.h) since 1998.  We already use it as our poisoning
> header and for so many other things common to the whole compiler.  It got
> a little messy when parts were split out like libcpp and fixincludes which
> now have their own top level directory and system.h file, but we do have
> it.
>
> I think most large projects should have a common header if they don't
> already.  It's just a good idea for so many reasons like this.  But if you
> don't have a common header, you might be able to stick
> -Dalloca=dont_use_alloca in the Makefile.  That should still work in the
> presence of system prototypes, it'll just declare alloca with the wrong
> name and you'll have to depend on the linker to catch you.

No. The system header will override your -D -
if a system header or a library header uses alloca,
it includes alloca.h and a typical alloca.h has #define for alloca
which will happily override whatever's in -D.

> Seriously, make a common header and do it there.

This may or may not make sense depending on the project.
And it certainly doesn't, for some of us.

> Note I'm not really against the new warning, I'm just pointing out that a
> mechanism already exists.

And I'm just pointing out that the existing mechanism doesn't work
for everybody.
It would be the best If there's some easy way to make this work
without changing the compiler, but I just don't see it.

Seongbae