[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Non-zero constant warning on RHEL 6.1 with 0.9.7



On 11/14/2011 10:36 PM, Eric Blake wrote:
On 11/14/2011 05:54 PM, Stefan Berger wrote:
On 11/11/2011 04:06 PM, Eric Blake wrote:
On 11/08/2011 11:46 PM, Justin Clift wrote:
Hi guys,

Just checking 0.9.7 on RHEL 6.1 x86_64.  Noticed this when compiling
with make -j 3:

      CC     libvirt_lxc-command.o
    util/buf.c: In function 'virBufferEscape':
    util/buf.c:469: warning: logical '&&' with non-zero constant will
always evaluate as true [-Wlogical-op]

Obviously not fatal, but it figured someone might want to keep things
warning free. :)
This is a bug in gcc, although I'm not sure if anyone has raised a bug
report against the gcc folks yet:
https://www.redhat.com/archives/libvir-list/2011-October/msg00837.html

I'm open to suggestions on how to work around it; perhaps we just need
to disable -Wlogical-op if glibc's headers are turning on the optimized
strchr (is that -D_FORTIFY_SOURCE that does it?) :(

At any rate, I agree that your proposed patch skirts the issue by using
strstr() instead of strchr(), so it would indeed do the trick (while
under the hood, strstr() on a single-byte needle tends to defer to
strchr() anyways).  It feels kind of gross, without at least a comment
explaining that we are working around a gcc bug in -Wlogical-op (and
even better, a URL of the gcc bug report); but I'm inclined to ACK it if
we can come up with an appropriate comment.

What about this here:

--- a/src/util/buf.c
+++ b/src/util/buf.c
@@ -466,7 +466,11 @@ virBufferEscape(virBufferPtr buf, const char *toescape,
     cur = str;
     out = escaped;
     while (*cur != 0) {
-        if (strchr(toescape, *cur))
+        /* strchr work-around for gcc 4.3 & 4.4 bug with -Wlogical-op
+         * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36513
+         */
+        char needle[2] = { *cur, 0 };
+        if (strstr(toescape, needle))
             *out++ = '\\';
         *out++ = *cur;
         cur++;


An even more aggressive patch would use strpbrk() to locate each
character that needs escaping and memcpy() to quickly copy chunks of
non-escaped text, rather than processing things one byte at a time, but
I'm not sure whether that would be a micro-optimization or whether this
function is called often enough to make it worth the extra complexity.

What does 'make V=1' show as the exact compiler line used when
triggering the error?  I still haven't been able to reproduce the bogus
compiler warning on a much smaller test case, but suspect I may be
missing a particular flag that makes it apparent.

libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../gnulib/lib -I../gnulib/lib -I../include -I../src/util -I../include -DIN_LIBVIRT -I/usr/include/libxml2 -Wall -W -Wformat-y2k -Wformat-security -Winit-self -Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wlogical-op -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wvolatile-register-var -Wdisabled-optimization -Wbuiltin-macro-redefined -Wmudflap -Wpacked-bitfield-compat -Wsync-nand -Wattributes -Wcoverage-mismatch -Wmultichar -Wno-missing-field-initializers -Wno-sign-compare -Wframe-larger-than=4096 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-all --param=ssp-buffer-size=4 -fexceptions -fasynchronous-unwind-tables -fdiagnostics-show-option -funit-at-a-time -g -O2 -MT libvirt_util_la-buf.lo -MD -MP -MF .deps/libvirt_util_la-buf.Tpo -c util/buf.c -fPIC -DPIC -o .libs/libvirt_util_la-buf.o
util/buf.c: In function 'virBufferEscape':
util/buf.c:469: warning: logical '&&' with non-zero constant will always evaluate as true [-Wlogical-op]


   Stefan


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]