|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 06/10] stubdom/xenstored: Fix uninitialised variables in lu_read_state()
Andrew Cooper writes ("[PATCH 06/10] stubdom/xenstored: Fix uninitialised
variables in lu_read_state()"):
> Various version of gcc, when compiling with -Og, complain:
>
> xenstored_control.c: In function ‘lu_read_state’:
> xenstored_control.c:540:11: error: ‘state.size’ is used uninitialized in
> this
> function [-Werror=uninitialized]
> if (state.size == 0)
> ~~~~~^~~~~
> xenstored_control.c:543:6: error: ‘state.buf’ may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
> pre = state.buf;
> ~~~~^~~~~~~~~~~
> xenstored_control.c:550:23: error: ‘state.buf’ may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
> (void *)head - state.buf < state.size;
> ~~~~~^~~~
> xenstored_control.c:550:35: error: ‘state.size’ may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
> (void *)head - state.buf < state.size;
> ~~~~~^~~~~
>
> Interestingly, this is only in the stubdom build. I can't identify any
> relevant differences vs the regular tools build.
#ifdef __MINIOS__
static void lu_get_dump_state(struct lu_dump_state *state)
{
}
So the compiler is right to complain that
lu_get_dump_state(&state);
if (state.size == 0)
barf_perror("No state found after live-update");
this will use state.size uninitialised.
It's probably just luck that this works at all, if it does,
anywhere...
Reviewed-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>
Release-Acked-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>
Ian.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |