Paolo Bonzini <[email protected]> writes:
> On 2/28/25 22:20, Patrick Venture wrote:
>> From: Peter Foley <[email protected]>
>> e.g.
>> qemu: Uninitialized value was created by an allocation of 'key_in_cur.i' in
>> the stack frame
>> qemu: #0 0xaaaac49f489c in keyval_parse_one
>> third_party/qemu/util/keyval.c:190:5
>> Signed-off-by: Peter Foley <[email protected]>
>> Signed-off-by: Patrick Venture <[email protected]>
>
> This is not a fix, since there's no bug to fix. It's just the tool
> complaining about something it can't reason on.
>
> Paolo
The code is designed to read @keyval_in_cur only in non-first iterations
of the loop. The previous iteration assigned to it then.
The two lines you quoted don't make sense to me. Is this the full
report you got? If not, show us the full report, please. Ideally with
a reproducer.
>> ---
>> util/keyval.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/util/keyval.c b/util/keyval.c
>> index a70629a481..f33c64079d 100644
>> --- a/util/keyval.c
>> +++ b/util/keyval.c
>> @@ -187,7 +187,7 @@ static const char *keyval_parse_one(QDict *qdict, const
>> char *params,
>> {
>> const char *key, *key_end, *val_end, *s, *end;
>> size_t len;
>> - char key_in_cur[128];
>> + char key_in_cur[128] = {};
Suspect overkill. Would "" do?
>> QDict *cur;
>> int ret;
>> QObject *next;
