qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes


From: Luiz Capitulino
Subject: Re: [Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
Date: Mon, 24 May 2010 16:38:18 -0300

On Mon, 24 May 2010 14:29:58 -0500
Anthony Liguori <address@hidden> wrote:

> On 05/20/2010 02:22 PM, Luiz Capitulino wrote:
> > On Thu, 20 May 2010 13:52:08 -0500
> > Anthony Liguori<address@hidden>  wrote:
> >
> >    
> >> On 05/20/2010 01:47 PM, Luiz Capitulino wrote:
> >>      
> >>> On Thu, 20 May 2010 11:55:00 -0500
> >>> Anthony Liguori<address@hidden>   wrote:
> >>>
> >>>
> >>>        
> >>>> On 05/20/2010 11:27 AM, Luiz Capitulino wrote:
> >>>>
> >>>>          
> >>>>> On Thu, 20 May 2010 10:50:41 -0500
> >>>>> Anthony Liguori<address@hidden>    wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>            
> >>>>>> On 05/20/2010 10:16 AM, Paolo Bonzini wrote:
> >>>>>>
> >>>>>>
> >>>>>>              
> >>>>>>> On 05/20/2010 03:44 PM, Luiz Capitulino wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>                
> >>>>>>>>      I think there's another issue in the handling of strings.
> >>>>>>>>
> >>>>>>>>      The spec says that valid unescaped chars are in the following 
> >>>>>>>> range:
> >>>>>>>>
> >>>>>>>>         unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>                  
> >>>>>> That's a spec bug IMHO.  Tab is %x09.  Surely you can include tabs in
> >>>>>> strings.  Any parser that didn't accept that would be broken.
> >>>>>>
> >>>>>>
> >>>>>>              
> >>>>>     Honestly, I had the impression this should be encoded as: %x5C 
> >>>>> %x74, but
> >>>>> if you're right, wouldn't this be true for other sequences as well?
> >>>>>
> >>>>>
> >>>>>            
> >>>> I don't think most reasonable clients are going to quote tabs as '\t'.
> >>>>
> >>>>          
> >>>    That would be a bug, wouldn't it?
> >>>
> >>>        
> >> Tabs are valid in JavaScript strings and I don't think it's reasonable
> >> to expect that a valid JavaScript string is not a valid JSON string.
> >>      
> >   IMO, we should do what the spec says and what bug free clients expect,
> > what we consider reasonable or unreasonable is a different matter.
> >    
> 
> How we encode strings is one thing, what we accept is something else.

 True.

> Why shouldn't we be liberal in what we accept?  It doesn't violate the 
> spec to accept more than it requires so why shouldn't we?

 For the reasons outlined by Avi, not sure how this serious this is though.



reply via email to

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