From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZm9w-00023F-7U for qemu-devel@nongnu.org; Tue, 26 Jan 2010 09:12:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZm9r-0001x4-Dq for qemu-devel@nongnu.org; Tue, 26 Jan 2010 09:12:47 -0500 Received: from [199.232.76.173] (port=52366 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZm9r-0001wq-9e for qemu-devel@nongnu.org; Tue, 26 Jan 2010 09:12:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49546) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZm9q-0007kf-UW for qemu-devel@nongnu.org; Tue, 26 Jan 2010 09:12:43 -0500 Message-ID: <4B5EF856.4050006@redhat.com> Date: Tue, 26 Jan 2010 16:12:38 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] win32: use PRId64 instead of %lld 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> <4B5EE450.9090004@linux.vnet.ibm.com> <4B5EF45B.30001@redhat.com> <4B5EF6C1.2020105@linux.vnet.ibm.com> In-Reply-To: <4B5EF6C1.2020105@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Markus Armbruster , "Michael S. Tsirkin" , Herve Poussineau , qemu-devel@nongnu.org, Luiz Capitulino On 01/26/2010 04:05 PM, Anthony Liguori wrote: > On 01/26/2010 07:55 AM, Avi Kivity wrote: >> The risk is that if we support a private extension (like '') and then >> json is officially extended to support a conflicting or similar >> syntax with a different meaning, then we cannot advance to the next >> revision of json without breaking compatibility. > > The paragraph I quoted from the RFC seems to suggest that the authors > of JSON boxed themselves in with respect to extending JSON. The > reason being that a conforming implementation is given free reign to > extend with "non-JSON forms or extensions". That would seem to > prevent any extension. A json generator is required to generate conforming text. So there are three choices: - reject 's - unofficially accept 's, nonconforming generators break if json changes, nor our problem - officially accept 's, look stupid when json changes > > Keep in mind, JSON is a proper subset of ECMAScript which means the > likelihood of extension going outside of ECMAScript would be extremely > unlikely. I don't expect JSON is ever going to change. Who knows? Let's not take unnecessary risks. -- error compiling committee.c: too many arguments to function