On 25 April 2012 13:54, Joseph S. Myers <jos...@codesourcery.com> wrote: > On Wed, 25 Apr 2012, Manuel López-Ibáñez wrote: > >> On 25 April 2012 00:01, Joseph S. Myers <jos...@codesourcery.com> wrote: >> > On Sun, 22 Apr 2012, Manuel López-Ibáñez wrote: >> > >> >> Wshadow warns whenever any declaration shadows a global function >> >> declaration. This is almost always noise, since most (always?) of the >> >> time one cannot mistakenly replace a function by another variable. The >> >> false positives are too common (Linus mentions using the name 'index' >> >> when including string.h). >> > >> > I think the correct rule would be: warn if a variable *with >> > pointer-to-function type* shadows a function, and warn if a nested >> > function shadows another function, but don't warn for variables shadowing >> > functions if the variable has any other type (because if the variable has >> > some type that isn't a pointer-to-function, no confusion is likely without >> > another error being given). >> >> Right. How does one check that a decl is a nested function? > > I think you should check if the decl has function type or pointer to > function type. (Nested functions are simply I think the only valid case > where you can end up with one function shadowing another; "has function > type" is the logical check rather than "is a nested function".)
Like so? Bootstrapped and regression tested on x86_64-linux-gnu.
OK?
2012-10-27 Manuel López-Ibáñez <m...@gcc.gnu.org>
PR c/53066
gcc/
* c/c-decl.c (warn_if_shadowing): Do not warn if a variable
shadows a function, unless the variable is a function or a
pointer-to-function.
* tree.h (FUNCTION_POINTER_TYPE_P): New.
testsuite/
* gcc.dg/Wshadow-4.c: New.
wshadow.diff
Description: Binary data
