On 2009/07/07 18:45, Jeffrey Middleton <jefr...@gmail.com> wrote: > Sorry, I emailed a bit on the mailing list a while back and thought I'd done > the best thing given what we talked about. Since I was going to have to > rewrite most of the code anyway to support long options, I thought reusing > code would be nice, to avoid having more versions of the same wheel, and > ncmpc's seemed good. > > A couple things about your list of points: > "error handling is missing" -- I'm not sure what error handling you're > referring to - it handles missing arguments, unknown options, and has a > provision for bad arguments. Note that this is an improvement; the parser > previously ignored unknown options, letting them be treated as unknown > commands instead. I didn't think I'd removed any error handling in the > process, but if I did I can certainly put it back in.
strdup() can fail. Don't strdup(), just pass the original pointer to lookup_long_option(). > "modifies argv strings" -- The original parser did this as well. > The function remove_index in options.c is run for every extracted > option. Right. The old parser sucked as well, but less than Kalle's ncmpc parser (IMHO). > "inconsistent code style" -- I can easily take care of this. Don't let it > be a deciding factor. > "twice as large, more complex" -- The net diffstat was +279/-208. options.c > is indeed much longer, but a lot of error checking and parsing/default > options have been moved into it from elsewhere in the code. I can prune out > some of the unnecessary complexity in the parser (e.g. callback function) > and get it even closer. Larger code because of more checks is a good thing in general, your patch description didn't point that out (that's why I'm asking). > So, tell me what you think is best. I can rewrite it from whatever approach > you want, and if short options really aren't a feature worth adding 50 lines > of code, that's fine, I'll just add them as long options to the previous > setup. I didn't think I'd be the only one who'd want short options, though. Personally, I don't care much about short options, but I think it's a good idea. ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
