On Tue, Aug 31, 2010 at 7:21 AM, Jes Sorensen <[email protected]> wrote:
> On 08/30/10 21:25, Blue Swirl wrote:
>> On Mon, Aug 30, 2010 at 3:35 PM, <[email protected]> wrote:
>>> From: Jes Sorensen <[email protected]>
>>>
>>> Hi,
>>>
>>> I started building QEMU with some more aggressive error flags to see
>>> what dropped out. I started fixing up some of the cases, removing
>>> unused arguments to functions, comparisons of unsigned types against
>>> negative values etc. and a few other minor changes to avoid compiler
>>> warnings.
>>
>> If the patches make all such warnings disappear, you could also
>> consider the same approach as taken by
>> 7ccfb2eb5f9d91bdb4139cb420a3b5f8deb2f6e8 and
>> ac41a6206fe9e1506010cd0aa9cf56ed3b37ae19.
>>
>> If a GCC flag can be enabled, it should not be just -Wextra, because
>> that means different things on different GCC versions, so please check
>> also
>> a316e3788df2781fda119e801e9b3d753f89b752.
>
> The one GCC flag I think we should enable, and probably was the one that
> caught the most bugs in my patch set is this one: -Wtype-limits
>
> There was only one false positive with this flag in block/blkdebug.c
> where it bails on a < 0 comparison of an enum. enum doesn't seem to be
> defined to being signed or unsigned, but a quick cast in that case would
> make that single false positive go away.
IIRC sparse or clang also complained about MIPS enums which don't fit
signed 32 bits. The problem could be solved by adding
BLKDEBUG_EVENT_MIN=1 and changing the comparison to check against
that.
But I found more cases in linux-user/{syscall,mmap,flatload}.c and
target-{mips,ppc}/op_helper.c. These should be fixed too before
enabling the flag.
