[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |