Re: [Qemu-devel] [PATCH v5 01/28] qapi: Document type-safety considerations

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2906 bytes --]

On 03/25/2015 02:11 PM, Eric Blake wrote:

>> The QObject types are QTYPE_NONE, QTYPE_QINT, QTYPE_QSTRING,
>> QTYPE_QDICT, QTYPE_QLIST, QTYPE_QFLOAT, QTYPE_QBOOL, QTYPE_QERROR.
>>
>> The connections JSON string - QTYPE_QSTRING, JSON object - QTYPE_QDICT,
>> JSON array - QTYPE_QLIST and JSON boolean - QTYPE_QBOOL are obvious
>> enough.
>>
>> If I remember correctly, our JSON parser chokes on the JSON keyword
>> null.

Yep, that is sadly still the case [1]:

$ qemu-kvm -qmp stdio -nodefaults
{"QMP": {"version": {"qemu": {"micro": 90, "minor": 2, "major": 2},
"package": " (qemu-2.3.0-0.1.rc0.fc21)"}, "capabilities": []}}
{"execute":"qmp_capabilities","id":null}
{"error": {"class": "GenericError", "desc": "Invalid JSON syntax"}}

Patch 17 adds support for it to qapi schemas, but not to our JSON
parser.  I guess that's yet another task to be solved before we turn on
argument defaults and introspection (as returning 'null' would be a
logical solution for introspecting the default value of an optional
string argument.  On the other hand, we could argue that using 'null' in
output of introspection still doesn't require the parser to accept
'null' on input;  the output direction of introspection is different
than the input direction of parsing a 'null' in user commands).

>>
>> That leaves just JSON numbers - QTYPE_QINT or QTYPE_QFLOAT.  Can an
>> anonymous union have a separate case for each of the two?

Yes.  Don't know why we'd want it, but the code currently handles it.
That is, this compiles just fine:

{ 'alternate': 'Foo', 'data': { 'a': 'int', 'b': 'number' } }
{ 'command': 'bar', 'data': { 'value': 'Foo' } }

allowing:
 {"execute":"bar", "arguments":{ "value":1 } }
 {"execute":"bar", "arguments":{ "value":1.0 } }
as operating on uint64_t vs. double (in practice, since '1' is also
valid input as a number, a double is sufficient without needing the
alternative of a uint64_t, unless you are simultaneously worrying about
precise integral values larger than 2**53 that lose data when converted
to double, while still allowing for inputs larger than 2**63 via double)

>>>  The format of a success response is:
>>>
>>> -{ "return": json-object, "id": json-value }
>>> +{ "return": json-entity, "id": json-value }
>>
>> Unlike the other json-FOOs we use, "entity" isn't defined in RFC4627.
>> "value" is, and we already use json-value.  What's the difference
>> between the two?
> 
> Umm, when I wrote that, I was thinking "id":json-value meant integer, so
> I wanted something that was not an integer.  But sure enough, json-value
> is precisely the term I wanted to use:

Well, given above at [1] that 'null' is a valid json-value but NOT
accepted by our parser, I guess we are not quite accurate here.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]