On 03/01/2017 08:48 AM, Daniel P. Berrange wrote: >> >> So now we have a dilemma: do we special case "" here, to be stuck with >> it even if we later add nullable-string support later, or do we go all >> the way to nullable-string support now? We've missed soft freeze for >> 2.9, so my vote is that it is okay to special case "" in this instance, >> even though we'll have to continue to support it indefinitely even if we >> gain nullable-string QMP. > > FYI, if QEMU ever sends a QMP reply whose value comes from a NULL string, > it turns that into "". IOW, on output "" and NULL are indistinguishable
That's a bug. My work to add a JSON output visitor requires a non-null string (it is only the qobject output visitor that silently converts NULL into "", and only because we haven't yet audited the broken callers). We WANT to reach the point where "" must be supplied when it is intended, and where a NULL string can be output as JSON null where appropriate. > > So from that POV, treating JSON nil and "" as indistiguishable on input > would be consistent with what we do on output. What we do on output is a result of laziness, not of user input. Codifying "" as NULL on user input is different than the existing treatment of NULL as "" on output. > > I'd only suggest allowing JSON nil on input, if we're willing change the > output code to map NULL -> nil, instead of NULL -> "". And yes, I think there ARE cases where we probably want to allow output of JSON null (probably in the same contexts where we want to allow null on input). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
