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.
"modifies argv strings" -- The original parser did this as well.  The
function remove_index in options.c is run for every extracted option.
"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.

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.

Jeffrey

On Tue, Jul 7, 2009 at 11:27 AM, Max Kellermann <m...@duempel.org> wrote:

> On 2009/07/07 18:07, Jeffrey Middleton <jefr...@gmail.com> wrote:
> > I have a version that uses getopt_long but I thought I was told that was
> a
> > bad idea because it comes from GNU getopt.h and we couldn't count on that
> > being part of embedded systems?  I can dig and find the email if it's
> > relevant.
>
> getopt_long() is a GNU extension, that's right.  getopt() is
> standardized in POSIX, and it's available on mingw32, but doesn't
> understand long options.
>
> By the way, what's wrong with mpc's current option parser?  Yours is
> twice as large, more complex, error handling is missing, inconsistent
> code style, modifies argv strings, and all it gives us is short
> options.
>
> Max
>
------------------------------------------------------------------------------
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

Reply via email to