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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list