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 02:15:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Luiz Capitulino <address@hidden> writes:

> On Fri, 19 Jul 2013 04:57:51 -0600
> Eric Blake <address@hidden> wrote:
>
>> On 07/18/2013 08:36 PM, Pawit Pornkitprasan wrote:
>> > The qmp_migrate method uses the 'blk' and 'inc' parameter without
>> > checking if they're valid or not (they may be uninitialized if
>> > command is received via QMP)
>> > 
>> > Signed-off-by: Pawit Pornkitprasan <address@hidden>
>> > ---
>> >  migration.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> Reviewed-by: Eric Blake <address@hidden>
>> 
>> However, wouldn't it be nice if we improved the qapi generator to
>> guarantee a sane default value for optional parameters, even when
>> has_value is false?
>
> We could do that for bool and pointers, but this wouldn't help
> integers and enums. Also, even if we had default values, I guess
> I'd enforce a common idiom for handling optionals as this is also
> a good practice for preventing bugs.

I disagree on pointers.

"have_ptr && ptr->..." is a stupid idiom.  The common idiom for safe
dereference is "ptr && ptr->...".

"bool have_ptr, FOO *ptr" in a parameter list is unidiomatic C.
Idiomatic is just "FOO *ptr".

Conciseness is a virtue.

For non-pointers, there's no special "don't have one" value, so we'd
have to declare a default value in the schema to get rid of the
have_FOO.



reply via email to

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