This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH]: xl: don't segfault parsing disk configs, suppor

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