On 10/16/19 9:50 AM, Jakub Jelinek wrote:
On Wed, Oct 16, 2019 at 09:43:49AM -0600, Martin Sebor wrote:
Should the warning trigger when the shadowing name results from
macro expansion? The author of a macro can't (in general) know
what context it's going to be used, and when different macros
come from two different third party headers, it would seem
pointless to force their users to jump through hoops just to
avoid the innocuous shadowing. Such as in this example:
#define Abs(x) \
__extension__ (({ __typeof__ (x) _x = x; _x < 0 ? -_x : _x; }))
#define Min(x, y) \
__extension__ (({ __typeof__ (x) _x = x; __typeof__ (y) _y = y; _x < _y ?
_x : _y; }))
int f (int x, int y)
{
return Abs (Min (x, y)); // -Wshadow for _x?
}
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?
Martin
PS The counterexample nicely illustrates why -Wself-init should
be in -Wall like in Clang or MSVC, or at least in -Wextra like in
ICC. Let me take it as a reminder to submit a patch for GCC 10.
