Il 22/06/2013 12:03, Stefan Weil ha scritto:
> Am 18.06.2013 12:13, schrieb Paolo Bonzini:
>> Il 07/06/2013 14:17, Markus Armbruster ha scritto:
>>>> diff --git a/util/iov.c b/util/iov.c
>>>> index cc6e837..b91cfb9 100644
>>>> --- a/util/iov.c
>>>> +++ b/util/iov.c
>>>> @@ -146,7 +146,7 @@ ssize_t iov_send_recv(int sockfd, struct iovec *iov,
>>>> unsigned iov_cnt,
>>>> {
>>>> ssize_t total = 0;
>>>> ssize_t ret;
>>>> - size_t orig_len, tail;
>>>> + size_t orig_len = 0, tail;
>>>> unsigned niov;
>>>>
>>>> while (bytes > 0) {
>>> Here are the uses of orig_len:
>>>
>>> if (tail) {
>>> /* second, fixup the last element, and remember the original
>>> * length */
>>> assert(niov < iov_cnt);
>>> assert(iov[niov].iov_len > tail);
>>> orig_len = iov[niov].iov_len;
>>> iov[niov++].iov_len = tail;
>>> }
>>>
>>> ret = do_send_recv(sockfd, iov, niov, do_send);
>>>
>>> /* Undo the changes above before checking for errors */
>>> if (tail) {
>>> iov[niov-1].iov_len = orig_len;
>>> }
>>>
>>>
>
> I get this warning, too, when I run a normal cross compilation with
> MinGW-w64:
>
> util/iov.c:190:33: warning: ‘orig_len’ may be used uninitialized in this
> function [-Wuninitialized]
>
> My build environment:
>
> Debian wheezy with packages gcc-mingw-w64-i686, gcc-mingw-w64-x86-64
> (4.6.3-14+8).
>
> A complete build results in 5 warnings. Here are the other 4 of them:
>
> hw/arm/spitz.c:280:0: warning: "MOD_SHIFT" redefined [enabled by default]
> hw/ppc/spapr.c:673:26: warning: cast from pointer to integer of
> different size [-Wpointer-to-int-cast]
Isn't this one a Win64 bug?
> hw/ppc/spapr_hcall.c:188:1: warning: control reaches end of non-void
> function [-Wreturn-type]
> hw/ppc/spapr_pci.c:454:1: warning: control reaches end of non-void
> function [-Wreturn-type]
I think you could report this to mingw. GCC should handle "if (!0)
foo()" just fine if foo is noreturn, perhaps the "assertion failure"
runtime function is not noreturn in mingw.
> I already sent a patch for the MOD_SHIFT issue.
>
> The remaining 3 warnings are also caused by code which makes it difficult
> for the compiler to detect that it is correct.
Not as hard as this one, though.
Anyway, I would be okay a fix that makes the code easier to follow for
compilers (and doesn't have too much duplication so that humans are also
happy). But adding "= 0" is the worst, because smart compilers will not
detect a human's mistakes anymore.
Paolo
