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

[Anthony Liguori]

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

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

Regards,

Anthony Liguori