[Top][All Lists]

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

A brief look at deprecating our JSON extensions over RFC 8259

From: Markus Armbruster
Subject: A brief look at deprecating our JSON extensions over RFC 8259
Date: Mon, 22 Feb 2021 15:57:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

We use JSON in several external interfaces:


* The guest agent's QMP

* QAPIfied command line options when the option argument starts with

* The block layer's pseudo-protocol "json:" (which can get embedded in
  image headers)

I *think* that's all.

The JSON parser we use for these interfaces supports extensions over RFC
8259.  Quoting json-lexer.c:

    - Extra escape sequence in strings:
      0x27 (apostrophe) is recognized after escape, too

    - Single-quoted strings:
      Like double-quoted strings, except they're delimited by %x27
      (apostrophe) instead of %x22 (quotation mark), and can't contain
      unescaped apostrophe, but can contain unescaped quotation mark.

    - Interpolation, if enabled:
      The lexer accepts %[A-Za-z0-9]*, and leaves rejecting invalid
      ones to the parser.

Ignore interpolation; it's never enabled at external interfaces.

This leaves single-quotes strings and the escape sequence to go with

I disabled them as an experiment.  Some 20 iotests, a qtest and two unit
tests explode.

The unit test testing the JSON parser is of course excused.

The remaining qtest and the unit test could perhaps be dismissed as
atypical use of QEMU from C.  The iotests less so, I think.

I looked at some iotest failures, and quickly found single-quoted
strings used with all external interfaces except for qemu-ga's QMP.

We could certainly tidy up the tests to stick to standard JSON.
However, the prevalence of single-quoted strings in iotests makes me
suspect that they are being used in the field as well.  Deprecating the
extension is likely more trouble than it's worth.


reply via email to

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