On 10/16/19, Jakub Jelinek <ja...@redhat.com> wrote: > On Wed, Oct 16, 2019 at 10:03:51AM -0600, Martin Sebor wrote: >> > The counter example would be: >> > #define F(x) \ >> > __extension__ (({ __typeof__ (x) _x = x; _x < 0 ? -_x : _x; })) >> > #define G(x) \ >> > __extension__ (({ __typeof__ (x) _x = x; F(_x); })) >> > where a -Wshadow diagnostics could point the author at a serious bug, >> > because in the expansion it will be __typeof__ (_x) _x = _x; ... >> >> True. I don't suppose there is a way to make it so the warning >> triggers for the counter example and not for the original, is >> there? > > Maybe look through the macro nesting context and if the shadowing > declaration comes from the same macro as shadowed declaration > or macro included directly or indirectly from the macro with shadowed > declaration, warn, otherwise not? > This might still not warn in case where the scope of the shadowing > declaration is created from multiple macros ({ coming from one, > }) from another one, but otherwise could work. > Perhaps -Wshadow-local needs multiple modes, the default one that > will have this macro handling and full one (=2) which would warn > regardless of macro definitions. >
I'm worried about the proliferation of the number of '=' signs here... there's already confusion as to whether the first '=' represents levels or just a different spelling of names, adding a second would only compound the confusion. > Jakub >