* [Qemu-devel] [PATCH 03/11] eepro100: initialize a variable in all cases
@ 2010-10-06 21:32 Blue Swirl
2010-10-07 9:31 ` Markus Armbruster
0 siblings, 1 reply; 4+ messages in thread
From: Blue Swirl @ 2010-10-06 21:32 UTC (permalink / raw)
To: qemu-devel, Stefan Weil
Compiling with GCC 4.6.0 20100925 produced warnings:
/src/qemu/hw/eepro100.c: In function 'eepro100_read4':
/src/qemu/hw/eepro100.c:1351:14: error: 'val' may be used
uninitialized in this function [-Werror=uninitialized]
/src/qemu/hw/eepro100.c: In function 'eepro100_read2':
/src/qemu/hw/eepro100.c:1328:14: error: 'val' may be used
uninitialized in this function [-Werror=uninitialized]
/src/qemu/hw/eepro100.c: In function 'eepro100_read1':
/src/qemu/hw/eepro100.c:1285:13: error: 'val' may be used
uninitialized in this function [-Werror=uninitialized]
Fix by initializing 'val' at start.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
---
hw/eepro100.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 2b75c8f..adc579f 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -1282,7 +1282,7 @@ static void eepro100_write_port(EEPRO100State *
s, uint32_t val)
static uint8_t eepro100_read1(EEPRO100State * s, uint32_t addr)
{
- uint8_t val;
+ uint8_t val = 0;
if (addr <= sizeof(s->mem) - sizeof(val)) {
memcpy(&val, &s->mem[addr], sizeof(val));
}
@@ -1325,7 +1325,7 @@ static uint8_t eepro100_read1(EEPRO100State * s,
uint32_t addr)
static uint16_t eepro100_read2(EEPRO100State * s, uint32_t addr)
{
- uint16_t val;
+ uint16_t val = 0;
if (addr <= sizeof(s->mem) - sizeof(val)) {
memcpy(&val, &s->mem[addr], sizeof(val));
}
@@ -1348,7 +1348,7 @@ static uint16_t eepro100_read2(EEPRO100State *
s, uint32_t addr)
static uint32_t eepro100_read4(EEPRO100State * s, uint32_t addr)
{
- uint32_t val;
+ uint32_t val = 0;
if (addr <= sizeof(s->mem) - sizeof(val)) {
memcpy(&val, &s->mem[addr], sizeof(val));
}
--
1.6.2.4
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [PATCH 03/11] eepro100: initialize a variable in all cases
2010-10-06 21:32 [Qemu-devel] [PATCH 03/11] eepro100: initialize a variable in all cases Blue Swirl
@ 2010-10-07 9:31 ` Markus Armbruster
2010-10-07 17:54 ` Blue Swirl
2010-10-07 17:54 ` Stefan Weil
0 siblings, 2 replies; 4+ messages in thread
From: Markus Armbruster @ 2010-10-07 9:31 UTC (permalink / raw)
To: Blue Swirl; +Cc: qemu-devel
Blue Swirl <blauwirbel@gmail.com> writes:
> Compiling with GCC 4.6.0 20100925 produced warnings:
> /src/qemu/hw/eepro100.c: In function 'eepro100_read4':
> /src/qemu/hw/eepro100.c:1351:14: error: 'val' may be used
> uninitialized in this function [-Werror=uninitialized]
> /src/qemu/hw/eepro100.c: In function 'eepro100_read2':
> /src/qemu/hw/eepro100.c:1328:14: error: 'val' may be used
> uninitialized in this function [-Werror=uninitialized]
> /src/qemu/hw/eepro100.c: In function 'eepro100_read1':
> /src/qemu/hw/eepro100.c:1285:13: error: 'val' may be used
> uninitialized in this function [-Werror=uninitialized]
>
> Fix by initializing 'val' at start.
I'm worried this sweeps bugs under the carpet.
When addr is out of bounds, these function return garbage. Your patch
makes them return 0 instead. Can that happen? Shouldn't we catch and
flag it?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [PATCH 03/11] eepro100: initialize a variable in all cases
2010-10-07 9:31 ` Markus Armbruster
@ 2010-10-07 17:54 ` Blue Swirl
2010-10-07 17:54 ` Stefan Weil
1 sibling, 0 replies; 4+ messages in thread
From: Blue Swirl @ 2010-10-07 17:54 UTC (permalink / raw)
To: Markus Armbruster; +Cc: qemu-devel
On Thu, Oct 7, 2010 at 9:31 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Blue Swirl <blauwirbel@gmail.com> writes:
>
>> Compiling with GCC 4.6.0 20100925 produced warnings:
>> /src/qemu/hw/eepro100.c: In function 'eepro100_read4':
>> /src/qemu/hw/eepro100.c:1351:14: error: 'val' may be used
>> uninitialized in this function [-Werror=uninitialized]
>> /src/qemu/hw/eepro100.c: In function 'eepro100_read2':
>> /src/qemu/hw/eepro100.c:1328:14: error: 'val' may be used
>> uninitialized in this function [-Werror=uninitialized]
>> /src/qemu/hw/eepro100.c: In function 'eepro100_read1':
>> /src/qemu/hw/eepro100.c:1285:13: error: 'val' may be used
>> uninitialized in this function [-Werror=uninitialized]
>>
>> Fix by initializing 'val' at start.
>
> I'm worried this sweeps bugs under the carpet.
>
> When addr is out of bounds, these function return garbage. Your patch
> makes them return 0 instead. Can that happen? Shouldn't we catch and
> flag it?
0 is a nice default value.
Adding an assert is not OK, guest shouldn't be able to terminate QEMU.
Adding a check which spams stdio is not so nice either.
I think it's even impossible with current QEMU for addr to be out of
bounds, the area is registered with size PCI_MEM_SIZE.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [PATCH 03/11] eepro100: initialize a variable in all cases
2010-10-07 9:31 ` Markus Armbruster
2010-10-07 17:54 ` Blue Swirl
@ 2010-10-07 17:54 ` Stefan Weil
1 sibling, 0 replies; 4+ messages in thread
From: Stefan Weil @ 2010-10-07 17:54 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Blue Swirl, qemu-devel
Am 07.10.2010 11:31, schrieb Markus Armbruster:
> Blue Swirl <blauwirbel@gmail.com> writes:
>
>> Compiling with GCC 4.6.0 20100925 produced warnings:
>> /src/qemu/hw/eepro100.c: In function 'eepro100_read4':
>> /src/qemu/hw/eepro100.c:1351:14: error: 'val' may be used
>> uninitialized in this function [-Werror=uninitialized]
>> /src/qemu/hw/eepro100.c: In function 'eepro100_read2':
>> /src/qemu/hw/eepro100.c:1328:14: error: 'val' may be used
>> uninitialized in this function [-Werror=uninitialized]
>> /src/qemu/hw/eepro100.c: In function 'eepro100_read1':
>> /src/qemu/hw/eepro100.c:1285:13: error: 'val' may be used
>> uninitialized in this function [-Werror=uninitialized]
>>
>> Fix by initializing 'val' at start.
>
> I'm worried this sweeps bugs under the carpet.
>
> When addr is out of bounds, these function return garbage. Your patch
> makes them return 0 instead. Can that happen? Shouldn't we catch and
> flag it?
We should.
I'll test new code which uses an assertion instead of the if statements,
so a new patch might be ready until end of next week.
Blue Swirl's patch does no harm, so it could be applied
nevertheless if compiler warnings should be fixed now
(I had the same kind of patch in my queue).
Stefan
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-10-07 17:54 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-06 21:32 [Qemu-devel] [PATCH 03/11] eepro100: initialize a variable in all cases Blue Swirl
2010-10-07 9:31 ` Markus Armbruster
2010-10-07 17:54 ` Blue Swirl
2010-10-07 17:54 ` Stefan Weil
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.