[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 |