qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH v4 04/28] qapi: Add parameter to visi


From: Markus Armbruster
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v4 04/28] qapi: Add parameter to visit_end_*
Date: Wed, 01 Jun 2016 17:36:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Eric Blake <address@hidden> writes:

> Rather than making the dealloc visitor track of stack of pointers
> remembered during visit_start_* in order to free them during
> visit_end_*, it's a lot easier to just make all callers pass the
> same pointer to visit_end_*.  The generated code has access to the
> same pointer, while all other users are doing virtual walks and
> can pass NULL.  The dealloc visitor is then greatly simplified.
>
> All three visit_end_*() functions intentionally take a void**,
> even though the visit_start_*() functions differ between void**,
> GenericList**, and GenericAlternate**.  This is done for several
> reasons: when doing a virtual walk, passing NULL doesn't care
> what the type is, but when doing a generated walk, we already
> have to cast the caller's specific FOO* to call visit_start,
> while using void** lets us use visit_end without a cast. Also,
> an upcoming patch will add a clone visitor that wants to use
> the same implementation for all three visit_end callbacks,
> which is made easier if all three share the same signature.
>
> Signed-off-by: Eric Blake <address@hidden>
[...]
> diff --git a/qapi/qmp-input-visitor.c b/qapi/qmp-input-visitor.c
> index aea90a1..84f32fc 100644
> --- a/qapi/qmp-input-visitor.c
> +++ b/qapi/qmp-input-visitor.c
> @@ -145,7 +145,7 @@ static void qmp_input_check_struct(Visitor *v, Error 
> **errp)
>      }
>  }
>
> -static void qmp_input_pop(Visitor *v)
> +static void qmp_input_pop(Visitor *v, void **obj)
>  {
>      QmpInputVisitor *qiv = to_qiv(v);
>      StackObject *tos = &qiv->stack[qiv->nb_stack - 1];

You could assert @obj matches tos->obj.  Same for the other visitors
that still need a stack.  Adding a stack to the ones that don't just for
the assertion seems excessive, though.

[...]



reply via email to

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