From: Jeroen Hofstee <jeroen@myspectrum.nl>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] fix: tools: kwbimage.c: Initialize headersz to suppress warning
Date: Fri, 21 Nov 2014 20:34:40 +0100 [thread overview]
Message-ID: <546F93D0.8040807@myspectrum.nl> (raw)
In-Reply-To: <20141121163059.31b19f9f@lilith>
Hello Albert,
On 21-11-14 16:30, Albert ARIBAUD wrote:
> On Fri, 21 Nov 2014 13:34:41 +0100, Jeroen Hofstee
> <jeroen@myspectrum.nl> wrote:
>
>>>> But oh well, if it fixes a warning :-)
>>> I didn't claim that there is a bug in the code :-).
>>>
>>> I just get annoying when on my continuous integration script I see the
>>> same warning for all cross compiled boards.
>> Wouldn't it be better to simply disable the -Wmaybe-uninitialized for
>> gcc?
> Disabling a warning is hiding potential dust under the carpet IMO
Agreed in general, but not for this one, since "fixing" is the
carpet, as far a I can tell. This is roughly the case which causes
the warning e.g. (and variant like this with a switch, etc):
----------------------------------------------------------------------------------
char *a;
if (something)
a = something_valid
[...]
if (something)
*a = 1;
----------------------------------------------------------------------------------
Some gcc versions start complaining about the second instance,
that it _might_ be used uninitialized.
With the "fix" this will no longer warn:
----------------------------------------------------------------------------------
char *a = 0; /* not valid, just set to stop gcc from complaining */
*a = 1; // paved away _error_, to suppress an invalid warning..
if (something)
a = something_valid
....
if (something)
*a = 1;
----------------------------------------------------------------------------------
Since 0 is a perfectly valid address in u-boot it should emit
no warning whatsoever, just crash at runtime.
> and
> the only justification I see as acceptable for doing so is when leaving
> the warning enabled would cause an obnoxiously high number of false
> positives.
Well let me add, if "fixing the warning" causes real error
to be hidden, we shouldn't "fix" the warnings by modifying
valid code.
Regards,
Jeroen
next prev parent reply other threads:[~2014-11-21 19:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-21 8:22 [U-Boot] [PATCH] fix: tools: kwbimage.c: Initialize headersz to suppress warning Lukasz Majewski
2014-11-21 8:35 ` Thomas Petazzoni
2014-11-21 9:20 ` Lukasz Majewski
2014-11-21 12:34 ` Jeroen Hofstee
2014-11-21 15:30 ` Albert ARIBAUD
2014-11-21 19:34 ` Jeroen Hofstee [this message]
2014-11-22 6:56 ` Lukasz Majewski
2014-11-22 12:17 ` Albert ARIBAUD
2014-11-23 17:38 ` Lukasz Majewski
2014-11-24 8:39 ` Lukasz Majewski
2014-11-24 18:00 ` Albert ARIBAUD
2014-12-08 11:40 ` Lukasz Majewski
2014-11-24 8:52 ` Guillaume Gardet
2014-11-21 9:54 ` Stefan Roese
2014-11-21 10:14 ` Heiko Schocher
2014-11-21 21:52 ` Albert ARIBAUD
2015-01-10 19:10 ` [U-Boot] " Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=546F93D0.8040807@myspectrum.nl \
--to=jeroen@myspectrum.nl \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox