Re: [PATCH 06/10] stubdom/xenstored: Fix uninitialised variables in lu_read_state()

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/02/2021 09:36, Jürgen Groß wrote:
> On 12.02.21 18:01, Andrew Cooper wrote:
>> On 12/02/2021 16:08, Jürgen Groß wrote:
>>> On 12.02.21 16:39, Andrew Cooper wrote:
>>>> 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.
>>>
>>> But me. :-)
>>>
>>> lu_get_dump_state() is empty for the stubdom case (this will change
>>> when
>>> LU is implemented for stubdom, too). In the daemon case this
>>> function is
>>> setting all the fields which are relevant.
>>
>> So I spotted that.  This instance of lu_read_state() is already within
>> the ifdefary, so doesn't get to see the empty stub (I think).
>
> There is only one instance of lu_read_state().

Ahh - I got the NO_LIVE_UPDATE and __MINIOS__ ifdefary inverted.  (It is
very confusing to follow).

I'll reword the commit message, but leave the fix the same.

~Andrew