On 10/18/2011 10:02 AM, Wen Congyang wrote:
At 10/18/2011 01:03 AM, Eric Blake Write:
On 10/17/2011 10:17 AM, Alex Jia wrote:
Eric, It's latest libvirt upstream, current commit id is commit 0a71c79.
# rpm -q glibc glibc-2.12-1.42.el6.x86_64
430 if (strchr(toescape, *cur))
CC libvirt_util_la-buf.lo util/buf.c: In function 'virBufferEscape': util/buf.c:430: warning: logical '&&' with non-zero constant will always evaluate as true [-Wlogical-op]
Something's screwy. There's no&& in that line, unless strchr() is a macro based on your particular compilation flags. I'm suspecting that this is a case of -D_FORTIFY_SOURCE going awry. I don't see how this could possibly be a libvirt issue; more likely, it is an issue with the choice of compiler flags you are using, coupled with an issue in the system headers causing the preprocessor to expand strchr() into something that tickles a spurious gcc warning.
Yes, strchr() is a macro, I use -E, and get the following:
while (*cur != 0) { if ((__extension__ (__builtin_constant_p (*cur)&& !__builtin_constant_p (toescape)&& (*cur) == '\0' ? (char *) __rawmemchr (toescape, *cur) : __builtin_strchr (toescape, *cur)))) *out++ = '\\'; *out++ = *cur; cur++; } *out = 0;
I reproduce this problem on RHEL6. Hmm, I test it on Fedora15, and the problem does not happen. I check the output with -E, and the macro strchr()'s expansion is the same as its expansion on RHEL6. I think it maybe gcc's problem. Thanks Wen Congyang
Thanks Wen Congyang
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list