From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZl18-0000ln-M5 for qemu-devel@nongnu.org; Tue, 26 Jan 2010 07:59:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZl13-0000iR-96 for qemu-devel@nongnu.org; Tue, 26 Jan 2010 07:59:37 -0500 Received: from [199.232.76.173] (port=44168 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZl12-0000iL-TX for qemu-devel@nongnu.org; Tue, 26 Jan 2010 07:59:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18309) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZl11-0005sX-Iy for qemu-devel@nongnu.org; Tue, 26 Jan 2010 07:59:32 -0500 Date: Tue, 26 Jan 2010 14:56:21 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCH] win32: use PRId64 instead of %lld Message-ID: <20100126125621.GD19036@redhat.com> References: <1264368221-3040-1-git-send-email-hpoussin@reactos.org> <20100125100905.GA9019@redhat.com> <20100125120348.461ce622@doriath> <20100125132719.23a483cf@doriath> <20100125153838.GB11161@redhat.com> <20100126094329.70719b6f@doriath> <4B5EE66A.1080600@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B5EE66A.1080600@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Herve Poussineau , Markus Armbruster , Luiz Capitulino On Tue, Jan 26, 2010 at 06:56:10AM -0600, Anthony Liguori wrote: > On 01/26/2010 06:37 AM, Markus Armbruster wrote: >>> This extension is only used internally by QEMU >>> >> Let me elaborate: when a QEMP client sends us 'a' over the wire, the >> parser rejects that as an error. At least that's what we've been >> promised when the extension was discussed. >> > > No, that's never been the case. I don't see the point. JSON allows it. > If a client comes to depend on it, so what? > > Regards, > > Anthony Liguori Then we'll have to support it forever. Asking clients to only depend on valid JSON will make sure we can use json library in the future, as well as allow easier debugging etc. -- MST