qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] migration: don't use uninitialized variables


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] migration: don't use uninitialized variables
Date: Tue, 30 Jul 2013 17:22:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On Tue, Jul 30, 2013 at 1:39 AM, Markus Armbruster <address@hidden> wrote:
>> Anthony Liguori <address@hidden> writes:
>>
>>> This was part of the discussion way back when this all was first
>>> introduced.  Since everything was open coded and we had to preserve
>>> the semantics, that was the only choice we had.
>>
>> Yes, there is a difference between an optional parameter with a default
>> value and one without.
>>
>> If you got a value QMP clients cannot send, the difference can be
>> eliminated: just pass this value to stand for "nothing".  This is the
>> case for pointers: just pass NULL.  Like everybody else does when
>> passing "nothing".
>>
>> When "nothing" is to be interpreted just like a context-independent
>> default value, then the difference doesn't matter.  The client doesn't
>> care, and the function handling the message becomes simpler.
>>
>> Only when "nothing" can mean different things do you really need both
>> have_FOO and FOO parameters.
>
> Right, and I'm saying that we have cases like this (especially with
> bools).  Unfortunately, there are places in the protocol that have

No argument there.

> tristate values for bool parameters and the behavior is distinctly
> different for false, true, and not-present.
>
> So yes, we could special case those bits and use sentinel values for
> everything else.  Just realize that we need to handle the above case.

Yes, we do, and it's understandable that only the most general case got
implemented.

>> I can't see why we couldn't introduce default values into the schema if
>> we wanted, and use them to simplify generated code.
>>
>> For pointers, we don't even need schema extensions to simplify away the
>> silly have_FOOs.
>
> Except you have to carefully audit all users to make sure of that.

For pointers, the audit should be trivial: change generator to omit the
have_FOO, compile, fix up the compile errors (drop have_FOO arguments,
replace have_FOO tests be FOO tests), done.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]