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

Stefan Berger stefanb at linux.vnet.ibm.com
Tue Nov 15 11:34:27 UTC 2011


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




More information about the libvir-list mailing list