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

Re: [Xen-devel] [PATCH]: xl: don't segfault parsing disk configs, support NULL physpath and ioemu:



On Thu, 2010-08-19 at 16:53 +0100, Ian Jackson wrote:
> Gianni Tedesco (3P) writes ("Re: [Xen-devel] [PATCH]: xl: don't segfault 
> parsing disk configs, support NULL physpath and ioemu:"):
> > It's true that it's longer but the nature of these types of parsers it's
> > a lot of very short lines :)
> 
> It adds 4164 characters and removes 1783.  Discounting leading
> whitespace it adds 2550 characters and removes 1085.  However you
> count it it's between 2x and 3x as long :-).
> 
> I always think state machine based parsers are very hard to read by
> eye.  That's why we have parser generators.
> 
> > I think it's clearer than a correct strtok() + handling all errors and
> > variations would be.
> 
> Perhaps so.
> 
> > It's your call, I know nothing of flex and its mysterious ways and my
> > pcre skills are limited to basic text-editor-fu... I agree that flex
> > probably makes the most sense.
> 
> I'll see if I can come up with a flex or pcre syntax that works and we
> can see what people think of it.

Fair enough. While we're on the subject why is there even a separate
libxlutil.so? It's not like the functionality is de-coupled and it seems
to me like this parser stuff should be compiled right in to libxenlight.

> > On the other hand whoever designed these formats seemed to want to make
> > them difficult to parse. Since it's all python I find myself wondering
> > why they didn't use a dictionary or a tuple.
> 
> Just don't go there :-).

OK, I suppose I'd rather not then :)


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.