From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqSS9-0003b6-AP for qemu-devel@nongnu.org; Wed, 23 Sep 2009 10:04:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqSS4-0003ZH-I5 for qemu-devel@nongnu.org; Wed, 23 Sep 2009 10:04:16 -0400 Received: from [199.232.76.173] (port=45357 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqSS4-0003ZC-Dy for qemu-devel@nongnu.org; Wed, 23 Sep 2009 10:04:12 -0400 Message-ID: <4ABA2AD2.3040005@redhat.com> Date: Wed, 23 Sep 2009 17:04:02 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20090921224430.610da97b@doriath> <4AB98034.3060608@codemonkey.ws> <20090923095701.GE29269@redhat.com> <4AB9FF35.9090208@redhat.com> <4ABA254A.3090703@gnu.org> In-Reply-To: <4ABA254A.3090703@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: ANN: QEMU Monitor Protocol git tree List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, Luiz Capitulino On 09/23/2009 04:40 PM, Paolo Bonzini wrote: > On 09/23/2009 12:57 PM, Avi Kivity wrote: >> On 09/23/2009 12:57 PM, Daniel P. Berrange wrote: >>>> Ignoring the dos-ism, since you can parse JSON with a regexp, why >>>> do we >>>> need explicit message boundaries? >>> I think it would be nice to be able to assume that each JSON message >>> will not cross a line-end boundary. Whether we use CRLF, just CR or >>> just LF I don't mind. Its much easier to search for a message boundary >>> by just doing strchr('\n') than having to actually parse the JSON or >>> use a regexp at that point. >> >> A good parser will consume exactly enough characters to make up an >> object or let you know if it needs more. I don't think using a regexp is >> warranted. > > Agreed, regexes are unnecessary. Also because a regex cannot parse > JSON; it can only detect _some_ invalid JSON inputs, and then only if > you're given an already complete input. > > In other words, there are Javascript JSON parsers that are just "match > a regexp and run eval on the input", but the actual parsing is done by > the Javascript interpreter using eval. The regexp is just avoiding > the security problems that are inherent in eval. On the other hand, the two parsers I looked at only accept a string as input, not a stream (strangely, one of them internally converts the string to a stream, but doesn't expose the stream interface), so record termination might be helpful to parsers. Would be best not to rely on it in the server, though. -- error compiling committee.c: too many arguments to function