qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 2/3] qapi: Add enum_table[] parameter to star


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v2 2/3] qapi: Add enum_table[] parameter to start_alternate
Date: Fri, 5 May 2017 17:51:45 -0300
User-agent: Mutt/1.8.0 (2017-02-23)

On Fri, May 05, 2017 at 03:45:01PM -0500, Eric Blake wrote:
> On 05/05/2017 03:11 PM, Eduardo Habkost wrote:
> > The new parameter will be used by the string input visitor to detect
> > alternate types that can't be parsed unambiguously.
> > 
> > Signed-off-by: Eduardo Habkost <address@hidden>
> > ---
> > Changes v1 -> v2:
> > * (new patch added to series)
> > ---
> 
> > +++ b/include/qapi/visitor.h
> > @@ -411,13 +411,21 @@ void visit_end_list(Visitor *v, void **list);
> >   * @supported_qtypes is a bit mask indicating which QTypes are supported
> >   * by the alternate.
> >   *
> > + * @enum_table contains the enum value lookup table, in case
> > + * strings in the input are going to be parsed as enums. Visitors
> > + * aren't required to validate string input according to
> > + * enum_table, as visit_type_enum() will be called automatically
> > + * if (*obj)->type is QTYPE_QSTRING.
> 
> Presumably, enum_table will be NULL if the alternate type does not
> include an enum?  [reads ahead] yes. Should be documented.
> 
> I'm less convinced we need this patch, if we can instead guarantee at
> QAPI-generation time that alternates are not possible if they would
> cause an ambiguity.

I am not 100% sure either. I just have the feeling that we are
likely to break the rules and allow ambiguous enums in
exceptional cases in the future, and then this code will be
useful.

That doesn't mean we need to maintain it in the source tree. We
can leave it on the git history, or just on the qemu-devel
archives.

-- 
Eduardo



reply via email to

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