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

To: "Gianni Tedesco (3P)" <gianni.tedesco@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH]: xl: don't segfault parsing disk configs, support NULL physpath and ioemu:
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Thu, 19 Aug 2010 16:53:13 +0100
Cc: Kamala Narasimhan <kamala.narasimhan@xxxxxxxxx>, Christoph Egger <Christoph.Egger@xxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 19 Aug 2010 08:53:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1282229882.3731.32.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1282228463.3731.27.camel@xxxxxxxxxxxxxxxxxxxxxx> <19565.17853.246902.357872@xxxxxxxxxxxxxxxxxxxxxxxx> <1282229882.3731.32.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.

> 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 :-).


Xen-devel mailing list