This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/81484] incorrect -Wint-in-bool-context warning
- From: "arnd at linaro dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 19 Jul 2017 14:37:30 +0000
- Subject: [Bug c/81484] incorrect -Wint-in-bool-context warning
- Auto-submitted: auto-generated
- References: <bug-81484-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81484
--- Comment #3 from Arnd Bergmann <arnd at linaro dot org> ---
It seems I got a little confused when I only looked at the initial patch that
was proposed, which was supposed to cover specifically the comparison followed
by ?: as in https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00115.html. I see now
that the patch that made it into the release also covers the more general case
and that seems intentional, it just causes false-positive warnings.
The part that still seems odd here is that the warning does not take into
account the macro: The caller just passes an expression as the integer argument
into the setsign() macro, while the macro tests it for being nonzero.
In the opposite case, I found a piece of kernel code that does not produce a
warning unless we preprocess it first (as ccache does for instance):
#define EINVAL 22
#define v4l2_subdev_call(sd, f) ((sd)->f ? (sd)->f(sd) : -EINVAL)
struct v4l2_subdev {
int (*g_sliced_fmt)(struct v4l2_subdev *sd);
};
int f(struct v4l2_subdev *sd)
{
if (v4l2_subdev_call(sd, g_sliced_fmt))
return -EINVAL;
return 0;
}
Here the macro contains the ?: operator while the caller contains the 'if()',
and something in gcc seems to decide not to warn about this, but that logic
does not identify the first example as an false-positive.