From: Anthony Liguori <anthony@codemonkey.ws>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
Wayne Xia <xiawenc@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH] Fix gcc-4.6 compiler error
Date: Sun, 31 Jul 2011 19:30:02 -0500 [thread overview]
Message-ID: <4E35F38A.7090305@codemonkey.ws> (raw)
In-Reply-To: <CAFEAcA8r5LEJtea8S9CpivizpC9dFh-j61XhxQhwGXADEBCZZA@mail.gmail.com>
On 07/29/2011 07:18 PM, Peter Maydell wrote:
> On 29 July 2011 20:30, Stefan Weil<weil@mail.berlios.de> wrote:
>> Commit 3d3b8303c6f83b9b245bc774af530a6403cc4ce6
>> breaks builds with gcc-4.6:
>>
>> hw/fw_cfg.c: In function ‘probe_splashfile’:
>> hw/fw_cfg.c:66:9: error: variable ‘fop_ret’ set but not used [-Werror=unused-but-set-variable]
>> hw/fw_cfg.c: In function ‘fw_cfg_bootsplash’:
>> hw/fw_cfg.c:130:9: error: variable ‘fop_ret’ set but not used [-Werror=unused-but-set-variable]
>>
>> Remove fop_ret. Testing the result of fread() is normally
>> a good idea, but I don't think it is needed here.
>
>> @@ -86,7 +85,7 @@ static FILE *probe_splashfile(char *filename, int *file_sizep, int *file_typep)
>> }
>> /* check magic ID */
>> fseek(fp, 0L, SEEK_SET);
>> - fop_ret = fread(buf, 1, 2, fp);
>> + (void)fread(buf, 1, 2, fp);
>
> Usually this kind of thing is added in order to stop gcc complaining about
> you ignoring the return value of a function which has been marked (by libc)
> as 'don't-ignore-return-value'. In such cases a "(void)" is not sufficient
> to suppress the "return value ignored" warning.
>
> At least some of these cases really should be checking fread return values;
> I see we also don't check fseek() return values either in all places. So
> the easiest fix is just to check all the fread() calls.
>
> Alternative suggestion: it would be easier to just slurp the whole file
> into memory (which is what we do once we've figured out it's an image)
> and then check the magic numbers in the memory buffer, which removes
> a lot of these unchecked function calls altogether. Since we're linking
> against glib anyway it looks like g_file_get_contents() would do 95%
> of the work for us. [disclaimer: I haven't used that API myself but it
> looks the right shape...g_malloc vs qemu_malloc issues, maybe?] Failing
> that, fopen/fstat/fread/fclose/check magic numbers.
As long as it's not mixed, it shouldn't be a problem.
I think using g_file_get_contents would make sense here.
Regards,
Anthony Liguori
>
> -- PMM
>
>
next prev parent reply other threads:[~2011-08-01 0:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-29 19:30 [Qemu-devel] [PATCH] Fix gcc-4.6 compiler error Stefan Weil
2011-07-30 0:18 ` Peter Maydell
2011-08-01 0:30 ` Anthony Liguori [this message]
2011-08-18 4:16 ` Zhi Yong Wu
2011-08-18 4:28 ` Peter Maydell
2011-08-19 2:48 ` Zhi Yong Wu
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=4E35F38A.7090305@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=xiawenc@linux.vnet.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.