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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list