[Bug c/78503] -Wint-in-bool-context false positive on unsigned multiplication

[edlinger at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78503

--- Comment #3 from Bernd Edlinger  ---
It is on purpose that the warning gets suppressed
when "(N) != 0" or "(N) + 0" is used, so that won't
go away.

But may I suggest the following for the XALLOCAVEC macro:

#define XALLOCAVEC(T, N) ((N) > 0 ? (T *) alloca (sizeof (T) * (N)) : (T *)0)

this would also avoid possible warnings about alloca with negative N.

[Bug c/78503] -Wint-in-bool-context false positive on unsigned multiplication

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78503

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-19
 CC||edlinger at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirming based on comment #1.  I CC the author of the warning for his input.

[Bug c/78503] -Wint-in-bool-context false positive on unsigned multiplication

[jbeulich at novell dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78503

jbeulich at novell dot com changed:

   What|Removed |Added

 CC||jbeulich at novell dot com

--- Comment #1 from jbeulich at novell dot com ---
We have something similar in the Xen hypervisor sources:

#define __compat_access_ok(d, addr, size) \
__compat_addr_ok(d, (unsigned long)(addr) + ((size) ? (size) - 1 : 0))

#define compat_access_ok(addr, size) \
__compat_access_ok(current->domain, addr, size)

#define compat_array_access_ok(addr,count,size) \
(likely((count) < (~0U / (size))) && \
 compat_access_ok(addr, (count) * (size)))

Instead of != 0 (which seems rather strange to not have the same effect of
producing a warning) for now we're adding in zero, but the example shows
clearly that replacing * by && is not an option here just like in the original
example.

Assuming that there's no intention to eliminate such false positives, could we
at least get a workaround allowing to suppress the warning which is going to be
usable also on future compiler versions (just like I'd expect the
presence/absence of != 0 to make not difference, I could imagine the + 0 to get
eliminated before inspecting the expression for whether to emit the warning).

Disabling the warning altogether does not seem to be desirable.