qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH] Suppress warning: zero-length gnu_printf format


From: Markus Armbruster
Subject: [Qemu-devel] Re: [PATCH] Suppress warning: zero-length gnu_printf format string
Date: Thu, 14 Oct 2010 11:20:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Blue Swirl <address@hidden> writes:

> On Wed, Oct 13, 2010 at 7:19 AM, Markus Armbruster <address@hidden> wrote:
>> Blue Swirl <address@hidden> writes:
>>
>>> On Mon, Oct 11, 2010 at 12:52 PM, Markus Armbruster <address@hidden> wrote:
>>>> Warns about this line in check-qjson.c:
>>>>    QObject *obj = qobject_from_json("");
>>>>
>>>> The obvious fix (add -Wno-format-zero-length to gcc_flags) doesn't
>>>> work, because -Wall switches it on again.  Fix by putting configured
>>>> flags last.
>>>
>>> This would disable the flag globally. I'd rather disable the flag only
>>> for check-qjson.o
>>
>> Is this warning worth the hassle?  What's the problem with empty format
>> strings?
>
> Your fix solves this specific case, but it also degrades the gcc
> checks of the mainstream code (slightly). I think the test suite need
> not follow the level of checking that should be applied to mainstream,
> or at least the warnings there should not be fatal.

"Degrade" implies we miss something that's "wrong" enough to be worth
avoiding.  What's wrong with empty format strings?

>>>                   or more generically, remove -Werror for checks. For
>>> example, there could be a check for how we handle invalid formats and
>>> then the sources would contain format strings that annoy GCC, but we
>>> wouldn't want warnings from that to stop the build.
>>
>> If you want to go that extra mile, feel free.  For me, --disable-werror
>> has been good enough.
>
> In that case, we could ignore the warning, since the only reporter is
> able to use a workaround ;-).
>
>> Regardless, I think we need the second patch hunk, to prevent -Wall from
>> trampling over $gcc_flags.
>
> I'm fine with that part.

Reposted separately.



reply via email to

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