qemu/tests/qapi-schema/ident-with-escape.json

# we allow escape sequences in strings, if they map back to ASCII
# { 'command': 'fooA', 'data': { 'bar1': 'str' } }
{ 'c\u006fmmand': '\u0066\u006f\u006FA',
  'd\u0061ta': { '\u0062\u0061\u00721': '\u0073\u0074\u0072' } }
qapi: Support (subset of) \u escapes in strings The handling of \ inside QAPI strings was less than ideal, and really only worked JSON's \/, \\, \", and our extension of \' (an obvious extension, when you realize we use '' instead of "" for strings). For other things, like '\n', it resulted in a literal 'n' instead of a newline. Of course, at the moment, we really have no use for escaped characters, as QAPI has to map to C identifiers, and we currently support ASCII only for that. But down the road, we may add support for default values for string parameters to a command or struct; if that happens, it would be nice to correctly support all JSON escape sequences, such as \n or \uXXXX. This gets us closer, by supporting Unicode escapes in the ASCII range. Since JSON does not require \OCTAL or \xXX escapes, and our QMP implementation does not understand them either, I intentionally reject it here, but it would be an easy addition if we desired it. Likewise, intentionally refusing the NUL byte means we don't have to worry about C strings being shorter than the qapi input. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> 2015-05-04 18:05:36 +03:00			`# we allow escape sequences in strings, if they map back to ASCII`
qapi: Add some expr tests Demonstrate that the qapi generator doesn't deal well with expressions that aren't up to par. Later patches will improve the expected results as the generator is made stricter. Only a few of the the added tests actually behave sanely at rejecting obvious problems or demonstrating success. Note that in some cases, we reject bad QAPI merely because our pseudo-JSON parser does not yet know how to parse numbers. This series does not address that, but when a later series adds support for numeric defaults of integer fields, the testsuite will ensure that we don't lose the error (and hopefully that the error message quality is improved). Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> 2015-05-04 18:05:14 +03:00			`# { 'command': 'fooA', 'data': { 'bar1': 'str' } }`
			`{ 'c\u006fmmand': '\u0066\u006f\u006FA',`
			`'d\u0061ta': { '\u0062\u0061\u00721': '\u0073\u0074\u0072' } }`