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().


Juergen