Re: [Qemu-block] [PATCH for-2.9 4/5] keyval: Document issues with 'any' and alternate types

[Eric Blake]

On 03/20/2017 07:55 AM, Markus Armbruster wrote:
> Signed-off-by: Markus Armbruster <address@hidden>
> ---
>  util/keyval.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/util/keyval.c b/util/keyval.c
> index 46cd540..93d5db6 100644
> --- a/util/keyval.c
> +++ b/util/keyval.c
> @@ -61,6 +61,16 @@
>   * "key absent" already means "optional object/array absent", which
>   * isn't the same as "empty object/array present".
>   *
> + * Design flaw: scalar values can only be strings; there is no way to
> + * denote numbers, true, false or null.  The special QObject input
> + * visitor returned by qobject_input_visitor_new_keyval() mostly hides
> + * this by automatically converting strings to the type the visitor
> + * expects.  Breaks down for alternate types and type 'any', where the
> + * visitor's expectation isn't clear.  Code visiting such types needs
> + * to do the conversion itself, but only when using this keyval
> + * visitor.  Awkward.  Alternate types without a string member don't
> + * work at all.

We've toyed with the idea of making socket parsing accept an alternate
between string and integer (right now it's string due to named port
support, even though most users end up accessing an integer causing a
lot of in-tree parsing/formatting between integers and strings) - that
will be one case that is particularly impacted by this design flaw, if
we ever go through with that idea.  But enough speculation about the
future - your patch as written is accurate for the present.

Reviewed-by: Eric Blake <address@hidden>

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature