qemu-trivial
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-trivial] [Qemu-devel] [PATCH] gtk: Fix compiler warnings with


From: Stefan Weil
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] gtk: Fix compiler warnings with -Werror=sign-compare
Date: Mon, 04 Nov 2013 21:23:57 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

Am 04.11.2013 21:07, schrieb Peter Maydell:
> On 4 November 2013 19:51, Stefan Weil <address@hidden> wrote:
>> With -Werror=sign-compare (not enabled by default), gcc shows these errors:
>>
>> ui/gtk.c: In function ‘gtk_release_modifiers’:
>> ui/gtk.c:288:19: error:
>>  comparison between signed and unsigned integer expressions 
>> [-Werror=sign-compare]
>> ui/gtk.c: In function ‘gd_key_event’:
>> ui/gtk.c:746:19: error:
>>  comparison between signed and unsigned integer expressions 
>> [-Werror=sign-compare]
> If this warning is going to complain about entirely
> safe and idiomatic code like
>
>    int i;
>    static const int some_array[] = {
>        0x2a, 0x36, 0x1d, 0x9d, 0x38, 0xb8, 0xdb, 0xdd,
>    };
>
>    for (i = 0; i < ARRAY_SIZE(some_array); i++) {
>        ...
>    }
>
> then I think it is more trouble than it is worth and we
> should leave it disabled.
>
> thanks
> -- PMM

Yes, we should leave it disabled for simple practical reasons: there are
too many warnings of this kind, so I don't expect they will be fixed in
the near future (I have no plan to send patches to fix them all - this
one was just in my way).

And yes, we should fix code which can be improved as easily as in the
above example. ARRAY_SIZE happens to be an unsigned size_t, so comparing
it to an unsigned value is better IMHO (I'm aware that there were
already discussions about using signed or unsigned integers).

-Wsign-compare is like other compiler warnings: it can detect some
really unwanted code, but a human reviewer won't always agree on the
results.It might be a good idea to support it somewhere in the far future.

Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]