On 01/26/2010 08:12 AM, Avi Kivity wrote:
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 meani
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
rev
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.
On 01/26/2010 02:47 PM, Anthony Liguori wrote:
On 01/26/2010 05:43 AM, Luiz Capitulino wrote:
The issue I see isn't related to unsigned. Apparently we currently
accept values such as 'a' as valid strings. Since this is not valid
json
we probably should reject it just in case we will want to s
On Tue, Jan 26, 2010 at 07:05:01AM -0600, Anthony Liguori wrote:
> On 01/26/2010 06:56 AM, Michael S. Tsirkin wrote:
>> 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 et
On 01/26/2010 07:08 AM, Daniel P. Berrange wrote:
On Tue, Jan 26, 2010 at 06:58:32AM -0600, Anthony Liguori wrote:
On 01/26/2010 06:46 AM, Michael S. Tsirkin wrote:
Yes, I agree we are comnpliant.
But I also think we should be strict and reject non-JSON
input just so that clients do n
On 01/26/2010 07:01 AM, Michael S. Tsirkin wrote:
For instance, at some point in time, we're going to do have to do
something about floating point representation.
What's the issue? There's '.' and there's 'e' ...
And maybe we won't need floating point ever ...
You cannot represent an
On Tue, Jan 26, 2010 at 06:58:32AM -0600, Anthony Liguori wrote:
> On 01/26/2010 06:46 AM, Michael S. Tsirkin wrote:
> >Yes, I agree we are comnpliant.
> >But I also think we should be strict and reject non-JSON
> >input just so that clients do not come to depend on it.
> >
>
> If we can make J
On 01/26/2010 06:56 AM, Michael S. Tsirkin wrote:
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.
As I mentioned in IRC, I'm not opposed to making this feature of
On Tue, Jan 26, 2010 at 06:58:32AM -0600, Anthony Liguori wrote:
> On 01/26/2010 06:46 AM, Michael S. Tsirkin wrote:
>> Yes, I agree we are comnpliant.
>> But I also think we should be strict and reject non-JSON
>> input just so that clients do not come to depend on it.
>>
>
> If we can make JS
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 th
On 01/26/2010 06:46 AM, Michael S. Tsirkin wrote:
Yes, I agree we are comnpliant.
But I also think we should be strict and reject non-JSON
input just so that clients do not come to depend on it.
If we can make JSON better while preserving compatibility and adhering
to the spec, why wouldn'
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
On Tue, Jan 26, 2010 at 06:47:12AM -0600, Anthony Liguori wrote:
> On 01/26/2010 05:43 AM, Luiz Capitulino wrote:
>>> The issue I see isn't related to unsigned. Apparently we currently
>>> accept values such as 'a' as valid strings. Since this is not valid json
>>> we probably should reject it jus
On 01/26/2010 05:43 AM, Luiz Capitulino wrote:
The issue I see isn't related to unsigned. Apparently we currently
accept values such as 'a' as valid strings. Since this is not valid json
we probably should reject it just in case we will want to switch to
another json library, otherwise clients m
Luiz Capitulino writes:
> On Mon, 25 Jan 2010 17:38:38 +0200
> "Michael S. Tsirkin" wrote:
[...]
>> The issue I see isn't related to unsigned. Apparently we currently
>> accept values such as 'a' as valid strings. Since this is not valid json
>> we probably should reject it just in case we will
On Mon, 25 Jan 2010 17:38:38 +0200
"Michael S. Tsirkin" wrote:
> On Mon, Jan 25, 2010 at 01:27:19PM -0200, Luiz Capitulino wrote:
> > On Mon, 25 Jan 2010 15:35:53 +0100
> > Markus Armbruster wrote:
> >
> > > Luiz Capitulino writes:
> > >
> > > > On Mon, 25 Jan 2010 12:09:06 +0200
> > > > "Mic
On Mon, Jan 25, 2010 at 07:47:56PM +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 25, 2010 at 06:32:06PM +0100, Stefan Weil wrote:
> > Michael S. Tsirkin schrieb:
> > > On Sun, Jan 24, 2010 at 09:23:41PM +, Herve Poussineau wrote:
> > >> Replace %lld occurrences by PRId64.
> > >
> > > This is w
Stefan Weil schrieb:
> Michael S. Tsirkin schrieb:
>> On Sun, Jan 24, 2010 at 09:23:41PM +, Herve Poussineau wrote:
>>> Replace %lld occurrences by PRId64.
>> This is wrong.
>> long long values should be printed with %lld.
>> size_t - with %zd. PRId64 is for int64_t.
>>
>
> size_t => %zu, ssize
On Mon, Jan 25, 2010 at 09:32:05PM +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 25, 2010 at 08:23:22PM +0100, Stefan Weil wrote:
> > Michael S. Tsirkin schrieb:
> > > On Mon, Jan 25, 2010 at 06:32:06PM +0100, Stefan Weil wrote:
> > >> Michael S. Tsirkin schrieb:
> > >>> On Sun, Jan 24, 2010 at 09
On Mon, Jan 25, 2010 at 08:23:22PM +0100, Stefan Weil wrote:
> Michael S. Tsirkin schrieb:
> > On Mon, Jan 25, 2010 at 06:32:06PM +0100, Stefan Weil wrote:
> >> Michael S. Tsirkin schrieb:
> >>> On Sun, Jan 24, 2010 at 09:23:41PM +, Herve Poussineau wrote:
> Replace %lld occurrences by PRI
Michael S. Tsirkin schrieb:
> On Mon, Jan 25, 2010 at 06:32:06PM +0100, Stefan Weil wrote:
>> Michael S. Tsirkin schrieb:
>>> On Sun, Jan 24, 2010 at 09:23:41PM +, Herve Poussineau wrote:
Replace %lld occurrences by PRId64.
>>> This is wrong.
>>> long long values should be printed with %ll
On Mon, Jan 25, 2010 at 06:32:06PM +0100, Stefan Weil wrote:
> Michael S. Tsirkin schrieb:
> > On Sun, Jan 24, 2010 at 09:23:41PM +, Herve Poussineau wrote:
> >> Replace %lld occurrences by PRId64.
> >
> > This is wrong.
> > long long values should be printed with %lld.
> > size_t - with %zd. P
Michael S. Tsirkin schrieb:
> On Sun, Jan 24, 2010 at 09:23:41PM +, Herve Poussineau wrote:
>> Replace %lld occurrences by PRId64.
>
> This is wrong.
> long long values should be printed with %lld.
> size_t - with %zd. PRId64 is for int64_t.
>
size_t => %zu, ssize_t => %zd might be better.
An
On Mon, Jan 25, 2010 at 01:27:19PM -0200, Luiz Capitulino wrote:
> On Mon, 25 Jan 2010 15:35:53 +0100
> Markus Armbruster wrote:
>
> > Luiz Capitulino writes:
> >
> > > On Mon, 25 Jan 2010 12:09:06 +0200
> > > "Michael S. Tsirkin" wrote:
> > [...]
> > >>
On Mon, 25 Jan 2010 15:35:53 +0100
Markus Armbruster wrote:
> Luiz Capitulino writes:
>
> > On Mon, 25 Jan 2010 12:09:06 +0200
> > "Michael S. Tsirkin" wrote:
> [...]
> >> Finally,
> >> don't we want unsigned values in protocol?
>
Luiz Capitulino writes:
> On Mon, 25 Jan 2010 12:09:06 +0200
> "Michael S. Tsirkin" wrote:
[...]
>> Finally,
>> don't we want unsigned values in protocol?
>
> JSON doesn't support them.
Uh, where does the RFC say that?
On Mon, 25 Jan 2010 12:09:06 +0200
"Michael S. Tsirkin" wrote:
> On Sun, Jan 24, 2010 at 09:23:41PM +, Herve Poussineau wrote:
> > Replace %lld occurrences by PRId64.
> > diff --git a/json-lexer.c b/json-lexer.c
> > index 53697c5..9d64920 100644
> > --- a/json-lexer.c
> > +++ b/json-lexer.c
>
On Sun, Jan 24, 2010 at 09:23:41PM +, Herve Poussineau wrote:
> Replace %lld occurrences by PRId64.
This is wrong.
long long values should be printed with %lld.
size_t - with %zd. PRId64 is for int64_t.
> Incidentally, this fixes use of curl on Windows, and prevents an assert
> when closing
29 matches
Mail list logo
