[PATCH]: New warning option -Walloca

[Ken Raeburn]

On Aug 31, 2007, at 17:58, Seongbae Park (박성배, 朴成培) wrote:
>> 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.

If alloca.h is protected against multiple inclusions, use -include to  
pull in a header file that includes alloca.h and then redefines  
alloca as discussed.  But a redefinition without #undef should at  
least get a warning.

(And defining it to something like "dont_use_alloca dont_use_alloca"  
is more likely to trigger a compile-time syntax error than just  
defining it to "dont_use_alloca".  I've played around with poisoning  
identifiers via cpp hacks before...)

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

Even if you add the compiler warning about uses of alloca, what's to  
stop someone from using "#pragma GCC diagnostic" to silence it, if  
they *really* want to get around it?

Ken