qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] [PATCH 0/6]: QMP: Fix issues in parser/lexer


From: Luiz Capitulino
Subject: [Qemu-devel] [PATCH 0/6]: QMP: Fix issues in parser/lexer
Date: Wed, 19 May 2010 18:15:27 -0300

 Hi Anthony,

 While investigating a QMP bug reported by a user, I've found a few issues
in our parser/lexer.

 The patches in this series fix the problems I was able to solve, but we
still have the following issues:

1. Our 'private extension' is open to the public

   Eg. The following input issued by a client is valid:

   { 'execute': 'query-pci' }

   I don't think it's a good idea to have clients relying on this kind of
   JSON extension.

   To fix this we could add a 'extension' flag to JSONLexer and set it to
   nonzero in internal functions (eg. qobject_from_jsonf()), of course that
   the lexer code should handle this too.

2. QMP doesn't check the return of json_message_parser_feed()

   Which means we don't handle JSON syntax errors. While the fix might seem
   trivial (ie. just return an error!), I'm not sure what's the best way
   to handle this, because the streamer seems to return multiple errors for
   the same input string.

   For example, this input:

   { "execute": yy_uu }

   Seems to return an error for each bad character (yy_uu), shouldn't it
   return only once and stop processing the whole string?

3. The lexer enter in ERROR state when processing is done

   Not sure whether this is an issue, but I found it while reviewing the code
   and maybe this is related with item 2 above.

   When json_lexer_feed_char() is finished scanning a string, (ie. ch='\0')
   the JSON_SKIP clause will set lexer->state to ERROR as there's no entry
   for '\0' in the IN_START array.

   Shouldn't we have a LEXER_DONE or something like it instead?

4. Lexer expects a 'terminal' char to process a token

   Which means clients must send a sort of end of line char, so that we
   process their input.

   Maybe I'm missing something here, but I thought that the whole point of
   writing our own parser was to avoid this.



reply via email to

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